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FIDEX 

FAULT ISOLATION AND DIAGNOSIS EXPERT 

An Expert System for Intelligent Computer Diagnostics of a 
Ka-Band Satellite Transponder System 

ABSTRACT 


The National Aeronautics and Space Administration (NASA), Lewis Research 
Center, in Cleveland Ohio, has recently completed the design of a Ka-band satellite 
transponder system, as part of the Advanced Communication Technology Satellite 
(ACTS) System. To enhance the reliability of this satellite, NASA funded The 
University of Akron to explore the application of an expert system to provide the 
transponder with an autonomous diagnosis capability. The result of this research was the 
development of a prototype diagnosis expert system called FIDE X* ; , Fault Isolation and 

Diagnosis EXpert. 

FIDEX is a frame-based expert system that was developed in the NEXPERT 
Object” 1 development environment by Neuron Data, Inc. It is a Microsoft Windows 
version 3.0 application, and was designed to operate on an Intel i80386 based Personal 
Computer system. 


‘Antecedent to the publication of a thesis by Donald Tallo, an application has been made for the 
licence of Copyright. FIDEX, in the context of Fault Isolation and Diagnostic Expert, will be 
protected under that licence. 
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As a frame-based system, FIDEX uses hierarchical structures to represent such 
items as the satellite’s: subsystems, components, sensors, and fault states. Its overall 
frame architecture integrates these hierarchical structures into a lattice that provides a 
flexible representation scheme and facilitates the maintenance of the knowledge-based 
system. To overcome limitations on the availability of sensor information, FIDEX uses 
an inexact reasoning technique based on the incrementally acquired evidence approach 
that was developed by Shortliffe during his MYCIN project. The system is also designed 
with a primitive learning ability through which it maintains a record of past diagnosis 
studies. This permits it to search first for those faults which are most likely to occur. 
And finally, FIDEX can detect abnormalities in the sensors which provide information 
on the transponder’s performance. This ability is used to first rule out simple sensor 
malfunctions. 

The overall design of the FIDEX system, with its generic structures and 
innovative features, makes it an applicable example for other types of diagnostic systems. 
This report discusses these aspects of FIDEX and summarizes the research involved in 
its development. 
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CHAPTER I 

INTRODUCTION 


The satellite network of the United States supports both the commercial and 
military sectors by providing an effective world-wide communication network. The 
reliability of this network represents a strategic resource for this country and a critical 
concern for the National Aeronautics and Space Administration (NASA). 

At present, the reliability of these satellite communication links are maintained 
through the intervention of ground terminal personnel. They use status information 
transmitted from the satellite to assess the possibility of system problems. Should these 
personnel suspect a problem with the satellite, a prescribed fault diagnosis/response 
strategy is followed. This process utilizes telemetry with mechanisms onboard the 
satellite to obtain required diagnostic information. Corrective measures are then 
communicated back to the switching mechanisms onboard the satellite which substitute 
redundant components. 

This process can only occur when the satellite is within communication range; 
during fly-by. Otherwise, telemetry with the satellite is not possible. This limitation 
poses little problem for satellites in geosynchronous orbits because they are in constant 
communication with their controlling ground terminals. However, many satellites in the 
U.S. network are in asynchronous orbits. These satellites can be out of telemetry with 
their controlling ground stations for as much as 50% of the time. This situation 
represents a significant handicap in the maintenance of these communication links. 
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Current research in artificial intelligence (AI) has sought to resolve this problem 
by increasing the capabilities of the satellite’s onboard diagnostic software. Since the 
mid 1980’s, NASA has been investigating AI technology to develop a diagnostic expert 
system which could be placed onboard the spacecraft. If such a system could replicate 
the diagnostic tasks that are performed by the ground terminal personnel, it could provide 
the satellite with an autonomous diagnosis capability. 

Success in this effort would offer the potential of significantly improving the 
reliability of satellite communication systems. Stephan [36] believes that achieving a 
high level of autonomy could allow the satellite to operate for months without ground 
contact. Such an enhancement could significantly reduce the cost of ground operations. 

In the summer of 1988, NASA-Lewis Research Center funded The University of 
Akron to study the application of such a diagnosis expert system. This report discusses 
that study and the resulting prototype expert system called FIDEX, Fault Isolation and 
Diagnosis Expert. 

1.1 Overview of the Application Area 

NASA has recently completed the design of a Ka-band (30/20-GHz) 
communication satellite transponder. This transponder system is to be integrated within 
the Advanced Communication Technology Satellite (ACTS) System and deployed early 
in 1993. The ACTS transponder is a multiple channel repeater which relays microwave 
communication signals between highly localized ground terminals. All references to the 
transponder in this report are directed towards the components of the communication 
system that will reside onboard the satellite. 
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1.1.1 Overview of the ACTS Communication System 

Figure 1.1 illustrates the ACTS communication system. The center figure, 
resembling a communication satellite, represents the ACTS transponder onboard the 
satellite. It is a typical multiple channel satellite transponder. Each channel of this 
system has an input and an output which are inter-linked through a matrix switch. 



A.C.T.S. 

GrojrxJ Terminol 



A.C.T.S. Tronsponder 



Figure 1.1: The ACTS Communication System 


The transponder receives its inputs on a channel up-link from a ground terminal 
system. In the input channel, this signal is first amplified and then down-converted from 
the up-link frequency to an intermediate frequency (IF) signal. The IF signal is routed 
through a matrix switch to one of the output channels. There, the IF signal is up- 
converted to the broadcast frequency, amplified, and broadcast on a down-link to the 
proper destination ground terminal system. Only two channels are being implemented 
in the current phase of SITE; SITE Phase II. Therefore, this discussion is limited to that 
of a two channel system. 
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Associated with each channel through the transponder is a ground terminal 
system. They are represented in Figure 1.1 by the two satellite dishes. These stations 
are currently in a state of development similar to the transponder system. In fact, the 
actual units are not being used in the SITE testing of the transponder. Simulated ground 
stations have been substituted in their place until the entire system is ready for integration 
testing. Therefore, the following discussion is limited to that of ground stations in 
general, and not specific to the ACTS ground terminals. 

Ground terminals represent the places of origin and destination for the signal 
transmitted through the transponder system. Respectively, these stations are called the 
originating and receiving ground terminals. In an originating ground station, digital 
information is encoded into a modulated signal. The modulated signal is up-converted 
to the up-link frequency, amplified and broadcast to the satellite. The satellite routes this 
signal as discussed above, and transmits it to the receiving ground terminal. In the 
receiving ground station, the down-link signal is amplified, down-converted, and 
demodulated back into digital information. In this manner, these three systems work 
together to provide cross-link communication between two geographically isolated places. 

The remainder of this section explains the inner workings of the transponder 
system. This discussion, however, is limited to the workings of the SITE model of the 
transponder. 

1.1.2 Overview of the ACTS Transponder System 

Figure 1.2 shows a schematic representation of the ACTS transponder. At 
present, only two of the multiple channels are implemented in its design. However, this 
proof of concept design can easily be expanded to incorporate additional links as the 
system design progresses. 
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RCVRLO 



UPXLO 

Figure L2: SITE Model of the ACTS Transponder System 


At present, the design of this transponder is being evaluated within the System 
Integration, Test, and Evaluation (SITE) testbed at NASA-Lewis. The SITE laboratory 2 
is used by NASA for validating designs and demonstrating the capabilities of satellite 
communications systems. This phase of development is valuable to NASA for refining 
the response of the various systems onboard the transponder. Another important aspect 
of SITE is the formulation of an understanding of these systems’ fault response. 

The first phase in the development of FIDEX was to study the diagnostic 
knowledge used by SITE personnel. This investigation began by studying the workings 
of the application area under normal conditions. This section is dedicated to 
summarizing that investigation. It is included to provide the background information on 
the ACTS transponder required by later discussions. For more detailed information on 


2 Space Electronics Division (SED), NASA-Lewis Research Center, Cleveland Ohio 44135 
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the transponder, please refer to the several papers listed in the SITE Related Publications 
appendix. 

The transponder is the part of the communication system which routes signals 
between ground terminals. It consists of all elements of the communication system which 
will reside onboard the satellite. This system is a comparatively small part of the 
satellite system. Other major systems onboard the spacecraft include power systems, 
diagnostic systems, telemetric systems, etc. This discussion is limited only to the 
transponder. Therefore, references to the satellite are implicitly directed to the 
transponder system onboard. 

Figure 1.2 shows the configuration of the transponder in its current SITE phase. 
As stated earlier, only two channels through the matrix switch are currently implemented. 
This will change as additional signal paths are added in future testing phases. However, 
the principles discussed here apply to any number of channels. 

Table 1.1 provides a legend for the labels in Figure 1.2. The names in the table 
are functionally descriptive. They are not the names used by NASA personnel. The 
following discussion traces the functionality of each transponder element listed in this 
table. 

Again, this section is only intended to provide background information on the 
workings of the transponder system. Therefore, each component’s operation is discussed 
in a general manner regarding its function in system operation. 



Table 1.1: Components of the ACTS Transponder System 


CH1RCVR 

CH2RCVR 

RCVRLO 

MSWITCH 

CH1MIX 

CH2MEX 

UPXLO 

GaAsFET 

TWTA 


A 

B 

C 

D 


G 

H 

I 

J 


E 

F 


K 

L 

M 

N 


PM_1 

PM_2 

PM_3 

PM_4 

PMJ 

PM_6 

PMJ7 

PM_8 


Major Transponder Components: 

Channel 1 Receiver Unit 
Channel 2 Receiver Unit 
Receiver Unit Local Oscillator 
Matrix Switch 

Channel 1 Up-Converter Mixer 
Channel 2 Up-Converter Mixer 
Up-Converter Mixer Local Oscillator 
Gallium-Arsenide Field Effect Transistor Amplifier 
Traveling Wave Tube Amplifier 

Intermediate Frequency Power Control (IFPC) Amplifiers: 

Channel 1 Matrix Switch Input IFPC Amplifier 
Channel 2 Matrix Switch Input IFPC Amplifier 
Channel 1 Up-converter Input IFPC Amplifier 
Channel 2 Up-converter Input IFPC Amplifier 

Intermediate Frequency Power Control Attenuators: 

Channel 1 Matrix Switch Input IFPC Attenuator 
Channel 2 Matrix Switch Input IFPC Attenuator 
Channel 1 Up-converter Input IFPC Attenuator 
Channel 2 Up-converter Input IFPC Attenuator 

High Power Amplifier Input Power Control (HPAIPC) Amplifiers: 
Channel 1 HPAIPC Driver Amplifier 
Channel 2 HPAIPC Driver Amplifier 

High Power Amplifier Input Power Control Attenuators: 

Channel 1 High Power Amplifier Input Attenuator 
Channel 1 HPAIPC Driver Input Attenuator 
Channel 2 HPAIPC Driver Input Attenuator 
Channel 2 High Power Amplifier Input Attenuator 

Signal Power Level Sensors: 

Channel 1 Matrix Switch Input Signal Power Level Sensor 
Channel 2 Matrix Switch Input Signal Power Level Sensor 
Channel 1 Up-converter Input Signal Power Level Sensor 
Channel 2 Up-converter Input Signal Power Level Sensor 
Channel 1 HPA Input Signal Power Level Sensor 
Channel 2 HPA Input Signal Power Level Sensor 
Channel 1 HPA Output Signal Power Level Sensor 
Channel 2 HPA Output Signal Power Level Sensor 
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Transponder System Control and Monitoring 

The first components of interest are those designated as pu_i through pm_8 in 
Figure 1.2. These components represent the transponder signal power level sensors 
which are present in the SITE Phase II model. These signal power level sensors report 
the power level of the transponder signal at various key locations throughout the system. 
All sensor readings are made available as diagnostic information via two sources. First, 
each sensor has a digital display which is visible on the transponder system control panel. 
This display offers a visual means of obtaining power meter readings. 

The second source for accessing sensory information is accomplished through an 
interface with a specialized computer called the Experiment Control and Monitoring 
(EC&M) Computer. This computer is discussed in greater detail later in this section. 

Experiment control is provided by the adjustment of the attenuators within the 
transponder. These attenuators can be either controlled manually or via an interface with 
the EC&M computer. Additionally, these attenuator settings are monitored by the 
EC&M and can be reported by either visual displays or interfacing with this computer. 
The power meters are also interfaced with the EC&M computer. This interface provides 
computer access to signal power level readings at the sensor locations. 

With this understanding of transponder control and monitoring, the workings of 
this system can be discussed on a component by component basis. Again, this discussion 
is based upon the workings of the transponder system during testing and evaluation 
experiments. 

The two channels of the transponder system are symmetrical about the matrix 
switch. Each channel has both an input and an output. A channel’s input consists of all 
components responsible for receiving an up-link broadcast and preparing it for input to 
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the matrix switch. A channel’s output consists of all components responsible for 
preparing the signal for broadcast on the down-link. 

Uplink Receivers and IF Frequency Conversion 

Channel 1 and 2 input channels are symmetrical about the matrix switch and can 
be discussed together. They receive up-link signals from their corresponding ground 
terminal system. This input signal is the modulated data stream being broadcast at 30 
GigaHertz (GHz) from the ground terminals. The 30-GHz Low Noise Receiver units on 
the channel 1 and 2 inputs, chircvr and chircvr in Figure 1.2, receive the up-link 
signal at a very low signal power level. The receiver units must provide the necessary 
amplification and down-convert the signal frequency to 2.5-GHz, the Intermediate 
Frequency (IF) level. 

This frequency down-conversion is accomplished via mixing with a local oscillator 
(LO) unit. Associated with both receiver units is the Receiver Local Oscillator, shown 
as component rcvrlo in Figure 1.2. This LO unit provides the 2.5-GHz reference 
necessary for down-conversion to the IF frequency. 

After down-conversion, the IF signal power levels are controlled by components 
a, B, g, and H. The Intermediate Frequency Power Control (IFPC) Amplifiers, 
components A and B, provide a constant 43-dB amplification to the IF signal. This high 
gain is compensated for by the IFPC Attenuators, components G and H. These 
attenuators are under control of the EC&M Computer and are incrementally adjustable 
in 1-dB steps. This control allows the IF signal power level to be maintained to within 
1-dB of its nominal level before input to the matrix switch. The IF signal power levels 
at the input to the matrix switch are monitored by the IF Power Level Sensors, pm_i and 
PM_2, and reported to the EC&M computer. 
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Ford Microwave Matrix Switch 

Interconnectivity between channel inputs and outputs is provided by the 
Microwave Matrix Switch, component mswitch in Figure 1.2. This matrix switch is a 
switching unit having multiple input and output channels. The internal switching 
mechanisms provide cross point connections for a full permutation of signal paths 
through the switch. However, in the transponder’s current phase of development, only 
two channels are implemented, channel 1 and channel 2. Consequently, only two of the 
many channels of the matrix switch are in use. This provides a total of four possible 
paths through the matrix switch. Table 1.2 shows the permutations of paths through the 
matrix switch. 


Table 1.2: Permutations of Signal Paths Through Matrix Switch 


Signal Path: 
PATH 11 
PATH 12 
PATH21 
PATH22 


Switch Interconnectivity: 

Channel 1 Input — Channel 1 Output 
Channel 1 Input — Channel 2 Output 
Channel 2 Input - Channel 1 Output 
Channel 2 Input — Channel 2 Output 


Inherent to the switching mechanisms, internal to the matrix switch and dependant 
upon signal path, is a certain degree of attenuation to the IF signal. Consequently, after 
signal path switching, the IF signal power level must be adjusted to maintain a proper 
signal strength. This signal power level control is affected by a second set of IFPC 
units, components c, D, I, and J in Figure 1.2. The IFPC Amplifiers, components c and 
D, again provide a constant 45-dB amplification to this signal, allowing the IFPC 
Attenuators, components P and Q, to provide 1-dB step control over the IF signal 
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strength. The IF signal power levels are monitored and reported to the EC&M by IF 
Signal Power Level Sensors pmj and pm_4. 

The channel outputs of the transponder system are responsible for preparing the 
IF signal for broadcasting on the down-link to the ground terminal systems. After 
switching, the transponder IF signal is considered to be in the output channel of its path 
through the transponder system. Again, the channel outputs of the transponder system 
are symmetrical about the matrix switch. The only exception to this symmetry occurs 
at the high power broadcast amplifiers before down-link. This exception is discussed 
later. 

IF/Downlink Frequency Conversion 

At this point in the component discussion, the signal has been directed through 
the matrix switch to its proper output channel. It is now ready to be prepared for 
transmission to the ground terminals. The first step in this preparation of the signal for 
broadcast is the frequency up-conversion of the 2.5-GHz IF signal to the 20-GHz 
broadcast frequency. This is accomplished by components CH1MIX and CH2MIX, which 
are the Transponder System Up-converter Multiplexers. These units combine the 2.5- 
GHz IF signal with a 20-GHz reference signal provided by the Transponder System Up- 
converter Local Oscillator, component UPXLO in Figure 1.2. 

After mixing, the signal power levels must be adjusted before input to the high 
power broadcast amplifier units, components goasfet and twta. This is accomplished 
by the High Power Amplifier Input Power Control (HPAIPC) units which follow the 
multiplexers, components E through N. The first HPAIPC attenuators in the output 
channel, components L and M, are fixed devices which provide a constant attenuation. 
Next, the HPAIPC Driver Amplifiers, components E and F, amplify the signal between 
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25 to 31-dB. The subsequent attenuators, HPAIPC attenuators, components K and N, are 
rotary vane pin diode attenuators which are continuously variable. This continuity in 
their adjustment allows the EC&M computer to have precise control of the signal power 
level on input to the high power broadcast amplifier units. The signal power levels at 
the input to the broadcast amplifiers are monitored and reported to the EC&M Computer 
via power sensors pm_5 and pm_6. 

The two high power amplifier units, now amplify the signal for broadcast on the 
down-link to the ground terminals. This is the point where the symmetry of the output 
channels fails. These amplifiers perform similar functions in the operation of the 
transponder system. However, they are distinctly different units and must be discussed 
separately. 

Gallium Arsenide (GaAs) FET Amplifier 

Component goasfet, the 20-GHz Solid State Amplifier, at the output of channel 
1, is a Gallium Arsenide Field Effect Transistor (GaAs FET) amplifier unit. This 
amplifier unit can be configured to operate at various set-points along its Input vs. Output 
(I/O) characteristic curve. By establishing a set-point, this amplifier can be configured 
to operate in one of three different modes; in a linear mode, in 1-dB compression or in 
a saturation mode. The following discussion helps to explain the multiple set-points for 
operation of an amplifier unit. 

As for any amplifier, the gain of the GaAs FET amplifier can be plotted as the 
magnitude of its output power level versus the magnitude of its input power level. This 
plot is often called the characteristic curve of the amplifier. Figure 1.3 shows a typical 
characteristic curve for a GaAs FET Amplifier. This figure is only intended to provide 
a conceptual understanding of the linear, compression and saturation ranges of amplifier 
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characteristic curves. It is not scaled to provide characteristic data about the GaAs FET 
amplifier specifically. 



Figure 1.3: Characteristics of a GaAs FET Amplifier 


This curve shows the non-linear relationship between the power at the output of 
an amplifier for a given input power level. Furthermore, this curve shows that the 
behavior of an amplifier is not consistent over the entire range of inputs. However, 
some generalizations can be made about amplifier behavior over specific regions of the 
curve. 

Although the characteristic curve is never actually linear, the lower end of the 
input power scale exhibits a behavior which approximates a linear relationship. The 
range of input power levels which produce this nearly linear characteristic is therefore 
called the Linear Range. Figure 1.3 shows this linear behavior in the range marked 
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"Linear." Notice that over this range, the characteristics of the amplifier could be 
approximated by a straight line. 

As the input power level is increased beyond this "Linear" range, the nonlinear 
parameters of an amplifier begin to become more pronounced. The characteristic curve 
begins to lose its linearity and compresses to a line of zero slope. Additionally, this 
compression is not constant and increases proportionally with the input power level. 
However, over a specific band of input power levels, the compression of the curve can 
be approximated as a 1-dB compression ratio. This range is therefore called the "1-dB 
Compression” range and is noted in Figure 1.3. 

As the magnitude of the input power level is increased beyond this 1-dB 
compression range, the compression of the characteristic curve becomes very 
pronounced. Its slope begins to approach zero rapidly, as the amplifier unit approaches 
saturation. The band of all input power levels above the 1-dB compression range exhibit 
this behavior. Therefore, this band of input power magnitudes is called the "Saturation" 
range and is also indicated on Figure 1.3. 

The configuration of the broadcast amplifier has a direct effect on the quality or 
accuracy of the communication signal. Ideally, an amplifier operates most efficiently 
near its saturated region. Near this range, the amplifier is providing the highest possible 
gain to an input signal. However, as the operating point of the amplifier approaches 
saturation, the amount of noise induced in the transmitted signal becomes greater. This 
noise is induced by the saturated amplifier as an increase in the harmonic content of the 
signal. Data bit errors begin to occur when this noise rises above a certain threshold 
limit. 

To prevent any loss of data in the modulated signal being transmitted through the 
satellite transponder, a set-point should be chosen in the linear region of operation. 
However, the gain characteristics of the amplifier in the linear range do not provide for 
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efficient amplification of the broadcast signal. Consequently, a trade-off must be made 
between the broadcast power required for efficient transmission and the linearity required 
for accurate transmission of data through the transponder. 

Multi-Mode Traveling Wave Tube Amplifier (TWTA) 

Component TWTA, the 20-GHz Multi-Mode Traveling Wave Tube Amplifier at the 
output of channel 2, is a Traveling Wave Tube Amplifier (TWTA). This amplifier can 
be configured to operate in various power modes. This multi-mode behavior allows the 
amplifier to operate along several characteristic curves; as opposed to a single curve like 
the GaAs FET. Specifically, the Multi-Mode TWTA can operate along one of three 
characteristic curves; each corresponding to one power mode of the TWTA. Figure 1.4 
shows typical power characteristics for a Multi-Mode TWTA. 

The Low Power Mode is designed for optimal efficiency in broadcast power. The 
gain of this mode is limited. However, under normal atmospheric conditions, this mode 
of operation should provide sufficient broadcast power for communication with the 
ground terminals. 

However, adverse atmospheric conditions often require a satellite to step up its 
broadcast power to overcome interferences. This TWTA can be stepped up to a Medium 
Power Mode to provide this compensation. The Medium mode of operation provides a 
higher gain and therefore an increase in the strength of the broadcast signal. The 
consequence is a greater power consumption by the amplifier unit. 

Similarly, should additional gain be required beyond that of the Medium Power 
Mode, a third configuration of the TWTA modes is available. The High Power Mode 
provides a very high gain to compensate for extremely strong atmospheric interferences, 
such as rain. 
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Figure 1.4: Characteristics of a Traveling Wave Tube Amplifier 


In addition to having the multi-mode capabilities, the TWTA can also be 
configured to operate at various set-points along each of its characteristic curves. Similar 
to the GaAs FET, the TWTA can operate linearly, in compression or in saturation. It 
has three operating points in each power mode; resulting in a total of nine possible 
configurations for the TWTA. 

The final components in the transmission paths through the transponder system 
are the transponder signal power level sensors PMJ and PM_8. After amplification by one 
of the broadcast amplifiers, the power levels of the down-link signal is reported to the 
EC&M via these sensors. These sensor readings indicate the output power of the 
transponder system, as the signal is transmitted to one of the ground terminals. In the 
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current phase of development, transmission of the signal to and from the ground 
terminals is simulated by a direct wave guide link. 

In summary, the transponder system consists of many components responsible for 
receiving, routing and broadcasting a communication signal between the ground 
terminals. A signal is received on a channel up-link from its originating ground terminal 
system. This signal is then down-converted in frequency to an intermediate frequency 
and routed through a matrix switch. This matrix switch is a switching network which 
channels a signal through one of four possible paths. After switching, the signal is up- 
converted in frequency and amplified by high power amplifiers and then broadcast on a 
channel down-link to its destination ground terminal. 

The next section looks into the computer control and monitoring performed by the 
various computer systems associated with the transponder and ground terminal. 

1.1.3 Overview of Computer Control & Monitoring 

The final topic of discussion in this overview is the computer network responsible 
for the control and monitoring of the satellite transponder and ground terminal systems. 
Figure 1.5 is an interface diagram which shows this network. 
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SATELLITE TRANSPONDER MATRIX SNITCH 



Figure 1.5: Computer Control and Monitoring Interface 


Digital Ground Terminal 

The first computer network of interest is a group of digital processors located in 
the ground terminal system. This group is collectively called the Digital Ground 
Terminal. It is comprised of the three simulated user terminals and the Data Bit Error 
Rate Registers. Again, as stated earlier, these processors are only present to simulate 
the existence of users. The actual ground terminal computer is currently under 
independent development, therefore, this discussion is limited to the operation of the 
simulated user processors. 

Located in the bottom right hand comer of Figure 1.5 are three blocks labeled as 
User Terminals. In the current stage of development for this system, only three system 
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users are being simulated. It is these three processors which are used to simulate the 
users. Each user terminal originates an individual data set to be transmitted through the 
communication system. During experimentation, large data sets are required for 
transmission. To accomplish this generation of a large data set, each user terminal 
generates a pseudo-random stream of bits. This data it then transmitted digitally to the 
signal processing components of the ground terminal. 

The signal processing components transmit this data through the satellite 
transponder system and then returns it digitally to the appropriate users. After the 
transmitted data is received at the appropriate user terminal, the data stream is checked 
for bit errors. This is accomplished by an Exclusive-OR (XOR) with the bits of the 
original data stream. The total of "Missed Bits" is calculated and a Bit Error Rate (BER) 
determined. This BER is simply the ratio of missed bits to the number of bits 
transmitted. 

This BER provides useful information about the performance of the 
communication under the experimental conditions. Therefore, the results of error 
checking for each of the users are stored in the three BER Registers shown in Figure 1.5. 
Since these registers are also digital components involved in the generation and 
evaluation of digital data, they are included in the network as part of the Digital Ground 
Terminal. In all, the components of this network, collectively called the Digital Ground 
Terminal, are responsible for the generation and evaluation of data to be transmitted 
during the testing and evaluation of the transponder system. 

Network Control Computer 

The next computer of interest is the block in Figure 1.5 labeled as the Network 
Control Computer (NCC). This computer is responsible for evaluating information from 
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the Ground Terminal System and appropriate control of the Transponder System. Its 
primary task is two fold. First, it must control the routing of the transmitted signal 
through the transponder system. And second, it must compensate for atmospheric 
disturbances by controlling the output signal power level of the satellite broadcast 
amplifiers. 

The NCC receives input from the simulated ground terminal users for the proper 
configuration of the matrix switch in the transponder system. Then, it configures the 
matrix switch to assure proper routing of data transmitted through the transponder. The 
NCC also is responsible for controlling the output power levels of the transponder’s 
broadcast signal. The primary reason for this output power level control is compensation 
for power losses which result from atmospheric disturbances, commonly called "Rain 
Fade." Located in the signal processing portion of the ground terminal system is a rain 
fade sensor. This sensor detects power attenuation caused by the rain fade simulator. 
When the down-link signal power level, reported by the rain fade sensor, falls below a 
certain threshold, the NCC directs the power processing unit of the Multi Mode TWTA 
to compensate for this attenuation by changing power modes. Conversely, to save 
power, if the rain fade sensor reports a decrease in attenuation, the NCC instructs the 
TWTA’s power processing unit to change to a lower power mode to compensate. 

Experiment Control & Monitoring Computer 

In the current phase of integrating, testing, and evaluating the transponder and its 
associated ground terminals, all operation is controlled and evaluated by the EC&M 
Computer. This computer is responsible for controlling all adjustable attenuators and the 
reporting of all sensory information. 
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Several attenuator settings can be controlled and reported by this computer. 
These settings are controlled by an analog voltage generated via an interface with the 
EC&M. The magnitude of this control voltage is also available for reporting the current 
levels of attenuation in these settings. 

In addition to controlling the transponder system signal power levels, the EC&M 
also provides a means of monitoring and evaluating the condition of the transponder and 
associated ground terminals by reporting sensory information. There are fifteen sensory 
inputs to the EC&M which report the readings of the nine transponder signal power level 
sensors and six data stream bit error rates. 

In the current phase of development of FIDEX, there is no direct interface 
between this EC&M computer and the diagnostic process. Currently, this information 
is input via user interrogation. However, the availability of this data would lend to a 
future implementation of an interface between this expert system and the EC&M 
computer. This concept is discussed in greater detail, when appropriate, later in this 
report. 

1.2 Project Definition 

The goal of this research project was to investigate the possibility of representing 
the knowledge gained during SITE in a diagnostic expert system. Such a study would 
then help to lay groundwork for a future system capable of providing the transponder 
with autonomous diagnosis capability. The research for this project progressed according 
to several key developmental phases: 


1. Domain Analysis : Study the operation of the application system under both normal and 
abnormal conditions 



22 

2. Knowledge Acquisition : Study and organize the knowledge used by the domain experts who 
perform fault diagnostics on application system 

3. Knowledge Representation: Design a scheme to model the application system and represent 
the knowledge required to detect, isolate, and diagnose its fault states 

4. Response Strategy Definition: Establish response strategies and procedures for all fault states 

5. Prototype Development: Develop, test, and modify a series of evolutionary prototype 

diagnostic expert systems 

6. Requirements Definition: Define the overall specifications for the final deliverable diagnostic 
expert system 

7. Final Development : Design, encode, integrate, test, and document the final deliverable 

expert system 

8. Life Cycle Analysis: Define and specify a maintenance schedule for the deliverable diagnostic 
expert system 

During these phases of development, several problems were encountered which 
reshaped the requirements of the project. Three problems of particular interest resulted 
from the evolutionary state of the ACTS transponder system. The requirements which 
these difficulties added to the project, and their solutions, highlight the major strengths 
of this expert system. 

The first of these difficulties became evident during domain analysis. The expert 
system was constrained to work with limited information on the operational condition of 
the transponder. Specifically, there were only a few sensors available to provide 
information on the response of the transponder system. This information was limited to 
the signal power level sensors, indicated in Figure 1.2 as pmj through pm_8, and a few 
bit-error-rate (BER) registers. This limited information was not completely adequate for 
assessing the condition of the transponder. In short, the sensors in the transponder were 
sparse in number, compared to the other components of the transponder system. 
Therefore, the isolation of a fault to a specific component based upon sensory 
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information alone was not possible. This limitation was termed the Sparse Sensor 
Problem. 

This problem also placed a high premium on the reliability of sensory 
information. Inconsistent or erroneous readings could render the expert system 
inoperable. Therefore, a method for resolving conflicts in sensory data was needed. 

A second problem was encountered during knowledge acquisition. A prerequisite 
for the development of an expert system is an extensive understanding of the application 
area. In a diagnostic application, this requirement dictates that the potential fault states 
of the system be well known. However, the ACTS transponder was still under 
evaluation, and a complete understanding of its fault response had yet to be formulated. 
This fact constrained the investigators to work with limited diagnostic knowledge. 
Without a clear definition of the transponder’s fault response, explicit diagnostic rules 
were not possible. Therefore, the expert system was prescribed to work with abstract, 
as well as concrete diagnostic knowledge. 

The final problem was also a result of the evolutionary state of the transponder 
system. The problem was that changes in the design of the system were always possible. 
These changes could range from modifications to design specifications, or even the 
addition of new modules. This situation made it difficult to develop a robust diagnostic 
agenda. 

Faced with these problems, the goal of this project changed more towards a study 
effort. Emphasis was placed on the development of techniques that would overcome 
these problems and permit the expert system to reason intelligently with only limited 
information. The system’s knowledge needed to be structured such that any change in 
the design of the transponder could easily be reflected in the structure of the expert 
system. All of these requirements placed a premium on the design of knowledge 
representation techniques and reasoning methods that were general and flexible. 
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The result of this effort was the development of a prototype diagnostic expert 
system called FIDEX, Fault Isolation and Diagnosis EXpert. This project demonstrated 
the feasibility of developing an intelligent computer diagnostic system not only for the 
ACTS transponder, but for space systems in general. 

1.3 General Approach to Solution 

The general approach taken in the development of this project followed the 
problem-solving approach used by the ground personnel who perform satellite 
diagnostics. This strategy was termed the Modular Approach to Diagnostics. In general, 
it follows the four tasks of: 

1. Fault Detection: Monitor the response of the transponder to determine whether it is 

functioning properly or not 

2. Fault Isolation: Narrow the range of suspected components to the smallest possible group 

3. Fault Diagnosis: Investigate the precise nature of the misbehavior and determine the 

component causing it 

4. Fault Response: Respond to the diagnosis in a robust and intelligent manner 

Fault Detection 

The purpose of the first task, Fault Detection, is to detect any misbehavior in the 
transponder performance. This task involves the analysis of current sensor information 
to ascribe qualitative descriptions to each sensor’s reading; either * good ’ or ’BAD." 
These descriptions are based on whether the data reported by a sensor exceeds a 
tolerance figure centered on its nominal or expected value. Sensor readings which are 
within tolerance receive a * good * description, and those which exceeded their tolerance 
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range are labeled as "BAD. " The detection of a fault is based upon establishing a "BAD" 
reading on any sensor. This indicates that a misbehavior exists in the transponder system 
and causes the next task to begin. 

Fault Isolation and Sensor Validation 

The second task in this approach is Fault Isolation. Its purpose is to isolate the 
suspected fault to the smallest possible group of components in the transponder. This is 
accomplished through a principle known as Error Propagation. This principle states that 
the observable symptoms of a misbehavior in a component propagates through all 
subsequent sensors in a signal path. The source of such a misbehavior can thus be 
concluded to lie in that signal path, prior to the detection of the misbehavior, and 
subsequent to the last sensor indicating a proper signal response. 

To implement this, the isolation task considers the qualitative description of all 
sensor readings ascribe by the detection phase. It locates a sensor reporting a "GOOD" 
reading which is followed by a "BAD" reading. However, because of the sparse sensor 
limitations, this approach can only isolate the source of the misbehavior to the group of 
components between these two sensors. For the purposes of this project, these groups 
of components are termed Subsystems , and are defined as the groups of components 
bounded signal power level sensors. 

The fault isolation task relies heavily upon the integrity of the data reported by 
the sensors. Should any sensor report erroneous data, this task will fail to reach a valid 
conclusion. Therefore, a subordinate Sensor Validation task was added to this diagnostic 
phase. 

The sub-task of sensor validation is designed to identify the possibility of a faulty 
sensor. This ability permits the FIDEX system to avoid the search for a non-existing 
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transponder fault. Sensor validation is also based on error propagation; however, in a 
slightly different fashion. Again, a signal producing a "BAD" sensor reading at one point 
in the transponder should result in a ' bad ’ reading on all subsequent sensors in that 
signal path. This task identifies the possibility of a faulted sensor if a "GOOD" reading 
instead is found. 

In either case, the purpose of isolation is to identify the subsystem containing the 
component causing the misbehavior. If this misbehavior is the result of a component 
failure, the subsystem identified by its input and output sensor readings is flagged as 
isolated. However, if the detected "BAD" sensor reading is the result of a faulty sensor, 
isolation flags the sensory components as the isolated subsystem. Once the source of the 
fault is isolated, the next task is initiated. 

Fault Diagnosis 

The third task, Fault Diagnosis , involves consulting a community of diagnostic 
expert systems. Each system is designed to address the problems of a specific subsystem 
within the transponder. Determining the appropriate diagnostic expert to be consulted 
is the final task of the isolation phase. 

These specialized diagnostic systems use knowledge which is rule-based and 
backward chaining in nature. The hypotheses for these rules represent the potential faults 
in the isolated subsystem. The order in which they are placed on the agenda is based on 
the history of the fault states. Maintaining this history permits FIDEX to pursue the 
most likely problems first. 

Each diagnostic system was also designed with an ability to perform inexact 
reasoning. This was done to overcome problems which resulted from limited information 
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about the transponder’s performance. Such an ability was important in that the FIDEX 
system would often need to make a "guess" at the most likely fault state. 

The inexact reasoning technique chosen for this project was based on the certainty 
theory given by Shortliffe [34]. It relies upon establishing incremental measures of belief 
or disbelief in rule conclusions. These two factors are then used to establish an overall 
confidence when a conclusion is supported by multiple rules. 

Fault Response 

The final task is Fault Response. The present strategy for fault response is to 
provide recommendations for reconfiguring the components or sensors. Plans are to 
include the capability to reconsider fault diagnosis if the recommended action was 
ineffective. FIDEX would retain its past diagnosis, including recommendations, and 
reconsider the problem with information made available following the corrections to the 
transponder. 

The remainder of this paper discusses the workings of the FIDEX system. It 
demonstrates the techniques discussed above, and by example, show their application to 
other types of diagnostic systems. 



CHAPTER H 

DEVELOPMENT ENVIRONMENT 


The long term objective for FIDEX was to permit it to acquire data on the 
transponder through the satellite’s onboard data acquisition systems. However, during 
its development of FIDEX it was decided to acquire this data interactively from the user. 
Therefore, a user interface between NEXPERT Object" and ToolBook was developed. 
These software packages operate in the Microsoft* Windows" environment. This permits 
them to interact and communicate through dynamic data exchange (DDE). 

Being a Windows" application, the interface is highly menu driven. The user 
enters information about the condition of the transponder through various forms and 
prompts. This data is then dynamically transferred to the NEXPERT" application where 
it is evaluated. The interface also allows NEXPERT" to prompt the user for information 
as it is required during the diagnostic process. 

The FIDEX system needed to be designed in a fashion that would allow it to 
incorporate changes to the transponder easily. Therefore, a frame-based approach was 
taken for knowledge representation. The system was also required to operate on an 
i80386 machine. The NEXPERT Object" development environment, by Neuron Data, 
Inc., was chosen as the development environment for the FIDEX system. 

NEXPERT" permits an object-oriented style of programming within 
class/subclass-object/subobject hierarchies. It includes message passing through active 
facets. It allows the encoding of general rules that scan frame hierarchies. It also 
permits access to database information contained in a variety of database formats. It can 
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be linked with and execute external programs. As a Microsoft* Windows application, 
it supports dynamic data exchange (DDE) and external message passing through dynamic 
link libraries (DLLs). All of these features were important in the design of FIDEX. 
Table 2.1 shows the basic system requirements for using NEXPERT Object . 

Table 2.1: NEXPERT Object" System Requirements 

► IBM PC Model 80, or compatible i80386 machine, with 1024-KBytes of base 
memory plus a minimum of 204 8 -KBytes extended memory. 

► Microsoft" Windows" version 3.0 or later. 

► Enhanced Graphics Array (EGA) or VGA color graphics adaptor with a minimum 
of 64-KBytes graphics memory. 

► 1.2-MByte or 1.44-MByte floppy disk drive. 

► Hard disk with a minimum of 6-MBytes available disk space. 

► Programmable bi-directional parallel port. 


CHAPTER HI 

KNOWLEDGE ENGINEERING 


The diagnostic knowledge of FIDEX is represented using both frame-based and 
rule-based techniques. This section discusses the structure of this hybrid framework. 
This is required to provide a background for discussions in subsequent chapters which 
describe the actual implementation of FIDEX in the syntax of NEXPERT Object . 

3.1 Frame-Based Architecture 

The expert system needed to be designed such that it would easily allow the 
incorporation of changes to the transponder. Therefore, it was decided that a 
frame-based approach for knowledge representation would be appropriate. Frame 
hierarchies were developed to represent the transponder’s components, subsystems, 
sensors and fault states. These hierarchies were interconnected into a network to enrich 
the overall knowledge representation structure. 

3.1.1 Structure of Components Class Hierarchy 

A frame hierarchy was created to provide a clear and efficient representation of 
all components in the transponder. Figure 3.1 shows this structure called the 
Components Class Hierarchy. This figure illustrates a convention that is maintained 
throughout in this report. Circles represent class frames and triangles represent object 
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frames. Lines indicate links between frames, with the arrows indicating the direction of 


inheritance. 



Figure 3*1: Components Class Hierarchy 


The root node in Figure 3.1 is a circle indicating a class frame called 
Components. This class was created to represent the commonality between all 
components in the transponder. It is divided into several subclasses; represented by the 
second level of class frames. Each of these subclasses describe the function of 
components in the transponder: amplifiers, attenuators, etc. The components are 
represented by object frames attached to these subclasses. 

3.1.2 Structure of Subsystems Class Hierarchy 

Each component is also associated with a subsystem of the transponder, see 
Figure 3.2. Several object frames are used to represent the collections of components 
called subsystems. These frames are then attached to a class frame called Subsystems. 









32 


Finally, the membership of a component to a particular subsystem is represented by 
attaching its object frame as a subobject of the appropriate subsystem object frame. 



3.1.3 Structure of Sensors Class Hierarchy 

Two types of sensory elements monitor both the response of the transponder and 
the relayed signal. The first type is signal power level sensors. The other type 
represents the data stream bit error rate (BER) registers located within the ground 
terminal systems. The information used for diagnosis is provided by these sensors. 
These sensors were represented by creating the class structure called Sensors for all 
sensory components shown in Figure 3.3. 

This structure is divided into subclasses according to the two types of sensors. 
Each sensor is then represented by an object attached to the appropriate type subclass. 
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The BER Sensors class is also divided into two subclasses according to their 
channel. This was done to simplify the analysis of frequency dependant fault states. It 
also demonstrates how class structures can be cascaded to further describe component 
function and organization. 

Like all other transponder components, sensory elements could potentially fail. 
Therefore, each sensor is also represented in FIDEX as a member of the Components 
world. Each sensory component is represented by an object frame. These frames are 
linked to their appropriate subclass type in both the components world and the sensors 


world. 
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3.1.4 Structure of Fault States Class Hierarchy 

The transponder fault states are represented as objects in a class structure called 
Fault States. This class is also divided into several subclasses. Each subclass frame 
represents the association of fault states to component types such as amplifier faults, 
attenuator faults, etc. Object frames representing the specific failure modes of the 
transponder are then attached to the appropriate subclasses. This structure, shown in 
Figure 3.4, enables FIDEX to reason about both known and abstract faults. 



This section has discussed the engineering of knowledge about the structure of the 
transponder and its faut states. The next sections discusses the engineering of knowledge 
about the diagnosis of fault states within the transponder. 
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3.2 Modular Approach to Diagnostics 

The basic approach was to divide the job of diagnosing faults within the 
transponder into a series of diagnostic tasks. Each of these tasks was separated into an 
individual module of the FIDEX system. 

The knowledge for the task of monitoring the response of the transponder in order 
to determine whether it is functioning properly or not was separated into an individual 
module called the Fault Detection Module. Similarly, the knowledge for the task of 
narrowing the range of suspected components to the smallest possible group was 
separated into an individual module called the Fault Isolation and Sensor Validation 
Module. 

The fault isolation task isolates the probable source of the fault to a subsystem of 
the transponder. For each of these subsystems, different knowledge is required to 
investigate the precise nature of a misbehavior and for determining the component 
causing it. Therefore, this knowledge was separated into a different Fault Diagnosis 
Module for each subsystem of the transponder system. Similarly, the strategies for 
responding to the diagnosis were also different for each subsystem. Therefore, the fault 
response task was incorporated into the diagnostic modules for the subsystems. 

Each of the above modules are loaded as they are needed in the diagnostic 
process. In this manner, the FIDEX system functions as a community of experts on the 
diagnosis of faults in the transponder system. 

3.3 Reasoning Techniques 

FIDEX reasons with two distinctly different techniques. The first technique, 
called absolute reasoning , is used to establish or reject the existence of predefined fault 
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states. The second technique, called abstract reasoning, is used to recover when the 
diagnostic task cannot reason effectively using the first technique. FIDEX uses the 
second technique to establish evidence in conceptual fault states. 

3.3.1 Absolute Reasoning 

In general, procedural knowledge which supports rules in absolute terms is 
associative knowledge. This type of knowledge associates conditions with the 
establishment or rejection of a conclusion. Two types of associative knowledge are used 
by FIDEX. 

The first type is directly associative. This knowledge directly associates 
conditions with conclusions. An example of this type of knowledge might be: If the 
data reported by a sensor reading exceeds its tolerance band, then the sensor’s reading 
is "bad." The condition of sensor data exceeding its acceptable range is directly 
associated with establishing a * bad * qualitative description for that reading. Rules which 
represent this type of knowledge are used to structure the strategies of the diagnostic 
tasks. 

However, the majority of the knowledge used in the task of fault diagnosis is 
supported by an accumulation of evidence. This type of knowledge is cumulatively 
associative. That is, the accumulation of several conditions is associated with the 
establishment or rejection of a conclusion. Moreover, each condition may contribute 
differently to that conclusion. An example of such knowledge might be: "A low signal 
power level might indicate internal phase lock failure in a local oscillator. * and "A high 
bit error rate is might indicate that the local oscillator is out of phase lock. " 

Neither conditions can be directly associated to establish or reject the conclusion 
of an internal phase lock failure. However, each contributes evidence to that conclusion. 
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When multiple rules contribute evidence toward a conclusion, the system must be able 
to accumulate this evidence. The FIDEX system has such an ability. 

3.3.2 Inexact Reasoning 

The FIDEX system uses inexact reasoning based on the MYCIN technique for 
incrementally accumulating evidence during the fault diagnosis task. This is because 
very few of the known fault states of the transponder system are supported by singular 
conditions. This section discusses the approach used in FIDEX for implementing the 
MYCIN technique. 

Not shown in Figure 3.4 is an additional node to the fault state hierarchy. The 
Fault States class is attached as a child of another class called Certainty Analysis. The 
certainty analysis class was created to provide the overhead required to perform inexact 
reasoning. All objects which represent hypotheses requiring certainty analysis are 
attached to this class. Because the fault state hypotheses require this, attaching their root 
node to the Certainty Analysis class provides them this overhead. 

Each fault state object inherits from the Certainty Analysis properties for 
accumulating: measures of belief, measures of disbelief, accumulated belief mb, md, ab, 
ad, and cf quantities that were discussed in section 3.3.2. As the diagnostic process 
acquires evidence in support or rejection of Fault State hypotheses, measures of belief 
and disbelief are assigned to these properties. 

Associated with these properties are algorithms for calculating the confidence 
factor according to the equations in 3.1 and 3.2. When measures of belief or disbelief 
are assigned, they are accumulated and an overall certainty is calculated. 
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3.3.3 Incremental Accumulation of Evidence 

FIDEX uses the incremental accumulation of evidence technique to establish or 
reject hypotheses which are supported by multiple rules, Shortliffe [34], The two 
equations given in 3.1 accumulate a measure of belief ab and disbelief ad in a hypothesis 
H. These two measures are then used by Equation 3.2 to establish an overall confidence 
cf in that hypothesis. 


AB(H) k - AB(H) k . x + MB(H) k \ 1 - AB(H) k . x ] 
AD(H) k - AD{H) k . x + MD(H) k [ 1 - AD{H) k . x 1 


CF{H) k - [ 


ABjfT^ - ADM, 

1 - mm(AB(H) k , AD(H) k ) 


(3.2) 


Rules which accumulate belief do not assign Boolean values to their associated 
hypothesis. Instead, they determine a measure of belief MB or measure of disbelief MD 
in that conclusion. These measures represent the degree to which the rule has 
contributed to the establishment or rejection of its hypothesis. The values which are 
assigned to these measures range between 0 and 1. Values close to 1 represent strong 
measures while values close to 0 represent weak measures. A value of 1 is generally not 
assigned; as it results in a Boolean value for ab or ad. 

Consider an arbitrary hypothesis H and assume that no evidence has been 
established toward belief in that conclusion; K — 0 and AB(H) 0 = 0. Establishing a fact 
in support of this conclusion might assign a measure of 0.2 to the belief in H, for 
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example MB(H), = 0.2. According to the first equation in 3.1, the accumulated belief in 
the hypothesis would then be ab(H) x = 0.2. The establishment of another fact in support 
of H might assign a measure of 0.5 to the belief in H, i.e. MB(H) 2 = 0.5. The 
accumulated belief in the hypothesis would then be incremented according to the first 
equations in 3.1; ab(H^ = 0.6. 

The accumulated measure of disbelief AD(H) is incremented similarly. However, 
this accumulation would be based on rules which establish measures of disbelief in a 
hypothesis MD(H This measure indicates evidence in rejection of the hypothesis. 

As rules ascribe MB(H^'s and MD(H) k ' s, and accumulated values are calculated, the 
overall confidence in a conclusion CFQik is calculated. Confidence factors range in value 
from -1 to 1. A value near -1 signifies little confidence in the hypothesis, or the 
rejection of the hypothesis. A value near 1 denotes a high level of confidence, or the 
establishment of the hypothesis. Values in between represent various degrees of 
confidence, with 0 meaning unknown. 

3.3.4 Abstract Reasoning 

Discussion to this point has been on the incremental accumulation of evidence 
toward concrete fault states. The next topic is discuss the application of these techniques 
for abstract reasoning. In general, knowledge which supports rules in abstract terms is 
conceptual knowledge . This type of knowledge is indirectly associative knowledge. It 
associates conditions to abstract ideas which are indirectly related to the rule being 
pursued. An example of this type of knowledge might be: A high bit error rate is 
typical of a misbehavior in one of the frequency conversion components. 
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FIDEX uses this type of reasoning to establish levels of confidence in class level 
fault categories. That is, it might reach a conclusion of the form: The observed 
symptoms are typical of those associated with a failure of the local oscillator. 

During the diagnostic task, FIDEX exhausts its knowledge about the fault states 
of the system. It is entirely possible that a failure mode might occur for which FIDEX 
has no knowledge. In that case, it would resort to confidence accumulated in class level 
fault states as its diagnostic conclusion. 

This abstract reasoning ability of FIDEX is implemented as follows. All of the 
fault state type subclasses defined in section 3.1.4 are attached as subclasses of the class 
Certainty Analysis. Therefore, they inherit information from this class, and permit 
measures of belief and disbelief to be assigned to the fault state classes. Levels of 
confidence can then be accumulated at this class, or conceptual, level. Using this 
technique, FIDEX can piece together information and reach conceptual conclusions about 
a fault. 

3.4 Learning and Adaptive Search Strategy 

There are two databases used by FIDEX. One contains information required to 
initialize parametric values of the system. Each record contains information on nominal 
readings, error tolerances, and other initial parameters. These values are loaded and 
stored in the appropriate slots of objects at run time or when FIDEX is initialized. This 
method of initialization was chosen to facilitate the maintenance of the system. 

The second database is used to provide FIDEX a limited learning capability. 
FIDEX stores the failure history of the transponder system in this database. Each known 
fault state is represented by a record that contains fields that represent the failure history 
of that fault state. Following diagnostics, FIDEX increments the history of the identified 
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fault. This record keeping is used to direct the search strategy of future sessions toward 
the most likely faults. 

The search strategy is adaptive in that the priorities by which known fault states 
are placed on the agenda is based upon the values maintained in the history database. 
A class level property of all fault states is the integer infrjoategory. The value of this 
property is retrieved from the database when the diagnostic task is initialized. This 
property is then assigned to the inference priority of the fault state hypothesis by slot 
actions. When the diagnostic task establishes a known fault state, the value of its 
inference category is incremented accordingly. The updated value is then stored in the 
learning database. 

This chapter has discussed the engineering of knowledge about the structure of 
the transponder system and diagnosing its fault states. The next several chapters discuss 
the techniques used to represent this knowledge in the knowledgebases of the FIDEX 
system. 



CHAPTER IV 

KNOWLEDGE REPRESENTATION 


As the previous chapter discussed the engineering of knowledge, this chapter 
discusses its frame-based representation in the FIDEX system. The kernel of this frame 
representation of the structure of the transponder is contained in the FIDEX. tkb 
knowledge base. A complete listing of that knowledge base is included in Appendix A 
of this report. The sections of this chapter discuss key segments of that knowledge base. 

4.1 Representation of Transponder System Components 

As discussed in chapter 3, a frame hierarchy was created to provide a clear and 
efficient representation of all components in the transponder. The root of this structure 
is a class frame called components. This class was created to represent the commonality 
between all components in the transponder. It is divided into several subclasses; 
represented by the second level of class frames, as shown in Figure 3.1. The 
components are represented by object frames attached to these subclasses. 

4.1.1 Property Definitions 

Code Segment 4. 1 shows a series of declarations that define the properties which 
are used to describe the components of the transponder system. These properties were 
defined to describe physical characteristics about a component; such as its name, 
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input/output components, etc. Some properties are used by FIDEX to give a component 
a self awareness. Other properties provide functional information about the components; 
such as its input and output signal power levels, gain, nominal gain, etc. The properties 
represent attributes of transponder components as follows. 

component _1N and componentjOUT are string properties that are used to encode 
structural information about the transponder components. These property values are 
initialized for every component to the names of the component objects at their input and 
output respectively. It is shown in the next chapter how these properties can be used to 
by an object to obtain information from its neighbors. 


Code Segment 4.1: Properties of the COMPONENTS Class 


(©PROPERTY = 

COMPONENTS 

©TYPE = String;) 

(©PROPERTY** 

COMPONENT_0 UT 

©TYPE “String;) 

(©PROPERTY = 

DESCRIPTION 

©TYPE “String;) 

(©PROPERTY = 

FREQUENCY 

©TYPE= Float;) 

(©PROPERTY = 

FREQUENCY'S 

©TYPE “Float;) 

(©PROPERTY = 

FREQUENCY_OUT 

©TYPE “Float;) 

(©PROPERTY = 

GAS 

©TYPE “Float;) 

(©PROPERTY = 

MODELJ3AS 

©TYPE “Float;) 

(©PROPERTY « 

MODEL JPOWER_S 

©TYPE “Float;) 

(©PROPERTY = 

MODEL_POWER_OUT 

@TYPE= Float;) 

(©PROPERTY = 

NAME 

©TYPE “Suing;) 

(©PROPERTY = 

NASA_ID 

©TYPE “String;) 

(©PROPERTY * 

NOMSAL_FREQUENCY 

©TYPE “Float;) 

(©PROPERTY “ 

NOMSAL~FREQUENCY_S 

©TYPE “Float;) 

(©PROPERTY = 

NOMSAL~FREQUENCY~OUT 

©TYPE “Float;) 

(©PROPERTY “ 

nomsal'gas 

©TYPE “Float;) 

(©PROPERTY « 

NOMSAL~POWER_S 

©TYPE “Float;) 

(©PROPERTY * 

NOMSAL~POWER~OUT 

©TYPE “Float;) 

(©PROPERTY - 

POWER_S 

©TYPE= Float;) 

(©PROPERTY “ 

POWER~OUT 

©TYPE “Float;) 


Another sting property called name is used to encode the name of a component 
object. This allows the object to communicate information about itself through the frame 
hierarchy. It is also useful for writing generic rules. Such rules operate on information 
posted in several blackboard frames. This property enables an object to post itself on 
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the blackboard and be operated upon by such rules. This utility is discussed in the next 
chapter. 

nasajd and description are string properties which are used to communicate 
information about a component object through the ToolBook™ interface, nasajd is 
initialized to the tag which NASA personnel use to reference transponder system 
components, description is initialized to a functional description of the component. 

The remaining properties are used to represent functional attributes of the 
transponder system components. Floating point properties are used to represent the 
propagation of the communication signal through a component of the transponder. 
Particularly, there are two aspects of the signal that are of interest: the signal power level 
and carrier frequency. The properties power in and frequency jn are used to represent 
these attributes of the transponder signal at the input to a component. Similarly, the 
properties powerout and frequency out are used to represent the signal power level 
and carrier frequency at the output of a component. The effect that a component has on 
the signal propagated through it is represented by the floating point properties CAIN and 
frequency. A component’s gain is its effect on the power level of the signal passed 
through it; be that an amplification or attenuation. If a component alters the earner 
frequency of the signal, that alteration is represented in the value of the frequency 
property; be it an upcon version or downcon version. 

All components have parametric values for their input/output signal power levels 
and frequencies. Moreover, their effect on the signal is defined by their design 
specifications. These nominal values are represented by the properties: 

NOMINAL FREQUENCY, NOMINAL JREQUENCYJN, NOMlNAL_FREQUENCY_OUT, NOMINAL _GAIN, 
NOMINAL J > OWERJN, and NOMINAL POWER OUT. 

Early in the development of the FIDEX system, a direction was taken toward the 
development of a system that used model-based reasoning. Although this approach was 
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abandoned early on, the properties required for its implementation were left within the 
components world. The reason for this was that it made no sense to destroy this 
capacity. If NASA would wish to expand this capability, the basic building blocks will 
exist within the FIDEX frame structure. Specifically, these properties are model_cain, 
MODEL_POWER_IN, and MODEL_POWER_OUT. 

4.1.2 Class Definitions 

The next definition, Code Segment 4.2, creates a class frame called components 
in the object space of the expert system. It establishes links to several subclasses and 
defines the properties discussed above as being associated with this class. The ten 
component subclasses listed represent different types of components in the transponder 
system. 

Several properties are required to represent attributes of specific types of 
components. These properties do not apply to components in general, but to specific 
types of transponder components. Code Segment 4.3 lists their definition. Due to the 
number of properties involved and their distribution between various subclasses, they are 
discussed with their corresponding subclasses later. 



Code Segment 4.2: Definition of the COMPONENTS Class 


(©CLASS = COMPONENTS 

(©SUBCLASSES = 

AMPLIFIERS 

ATTENUATORS 

LOCA LOSCILLATORS 

RECEIVERS 

POWER_METERS 

BER_REGISTERS 

SWITCHES 

GaAsFETS 

TWTAS 

MIXERS ) 

(©PROPERTIES = 

COMPONENT_IN 

COMPONENT~OUT 

DESCRIPTION” 

FREQUENCY 
FREQUENCY_IN 
FREQUENCY - © UT 
GAIN 

MODEL_GAIN 
MODEL j>OWER_IN 
MODEL - POWER - OUT 
NAME - 
NASA_ID 

NOMINALJFREQUENCY 

NOMINAL - FREQUENCY^IN 

NOMINAL_FREQUENCY - OUT 

NOMINALJ3AIN 

nominal - powerjn 

NOMINAL" POWER_OUT 
POWERIN 

POWER - OUT ) ) 



Code Segment 4.3: Properties of COMPONENTS Subclasses 


(©PROPERTY = 
(©PROPERTY = 
(©PROPERTY- 
(©PROPERTY — 
(©PROPERTY = 
(©PROPERTY = 
(©PROPERTY — 
(©PROPERTY - 
(©PROPERTY- 
(©PROPERTY - 
(©PROPERTY = 
(©PROPERTY — 
(©PROPERTY — 
(©PROPERTY - 
(©PROPERTY - 
(©PROPERTY — 
(©PROPERTY- 
(©PROPERTY- 
(©PROPERTY- 
(©PROPERTY- 
(©PROPERTY- 
(©PROPERTY- 
(©PROPERTY- 
(©PROPERTY - 
(©PROPERTY- 
(©PROPERTY- 
(©PROPERTY- 
(©PROPERTY- 
(©PROPERTY- 
(©PROPERTY- 
(©PROPERTY- 
(©PROPERTY- 
(©PROPERTY- 
(©PROPERTY- 
(©PROPERTY - 


BIAS_CURRENT ©TYPE= 

BIAS~VOLTAGE ©TYPE = 

COMPONENT_IN_2 ©TYPE** 

COMPONENT_OUT_2 ©TYPE** 

CONFIG “ " ©TYPE** 

DRAIN_V0LTAGE ©TYPE= 

FREQUENCY^ ©TYPE= 

FREQUENCY'lN_2 @TYPE= 

FREQ UENCYO UT_2 ©TYPE= 

GAIN2 " ’ ©TYPE= 

gate'voltaoe ©TYPE= 

LOJNPUT_FREQUENCY ©TYPE* 

LOJNPUT~POWER ©TYPE= 

LO UNTT " ©TYPE= 

MODEL_GALN_2 ©TYPE = 

MODEL~POWER_IN_2 ©TYPE = 

model”power“out_2 ©TYPE* 

MODEL~SETTINa ©TYPE* 

NOMINAL_BIAS_CURRENT ©TYPE* 

NOMINAL~BIAS~VOLTAGE ©TYPE* 

NOMINAL' DRA^VOLTAGE ©TYPE* 

NOMINAL”FREQUENCY_2 ©TYPE* 

NO MIN A L”FREQ UEN CY_IN_2 
NOMINA L~FRJ£QUENCY~OUT_2 
NOMINAL~GAIN_2 ~ ~ ©TYPE* 

NOMINAL“GATE~ VOLTAGE ©TYPE * 

NOMINAL_LO_INPUT_FREQUENCY 
N0MINAL_L0jNPUT_P0WER 
NOMINAL~POWER_IN_2 ©TYPE* 

NOMINA l'pO\VTR[oUT_2 ©TYPE* 

NOMINAL~SETTING ” ©TYPE* 

POWER_IN_2 ©TYPE 

PO WER~0 UT_2 ©TYPE 

SETTING ©TYPE 

SETTING ERROR ©TYPE 


Float;) 

Float;) 

String;) 

String;) 

String;) 

Float;) 

Float;) 

Float;) 

Float;) 

Float;) 

Float;) 

Float;) 

Float;) 

String;) 

Float;) 

Float;) 

Float;) 

Float;) 

Float;) 

Float;) 

Float;) 

Float;) 

©TYPE -Boat;) 
©TYPE- Float;) 

* Float;) 

* Float;) 

©TYPE- Boat;) 
©TYPE- Float;) 
Boat;) 

Boat;) 

Boat;) 

Float;) 

=Boat;) 

= Float;) 

*Boat;) 
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Each subclass defined in Code Segments 4.4a and 4.4b represent the subclass 
nodes introduced in Figure 3.1 in section 3.1.1. Again one class is created for each 
basic type of category of component in the transponder system. The names are 
descriptive but are explained for clarity. 


Code Segment 4,4a: Definition of the COMPONENTS Subclasses 


(©CLASS - AMPLIFIERS 

(©PROPERTIES* 

BIAS_CURRENT 

BlAS~VOLTAGE 

DRAIN_VOLTAGE 

oateJvoltage 

NOMINAL_BIAS_CURRENT 
N0MINAL~BIAS”V0LTAGE 
NOMINAL~DRAIN_VOLTAGE 
NOMINAL~GATE_VOLTAGE ) ) 

(©CLASS* ATTENUATORS 

(©PROPERTIES* 

MODEL_SETTING 
NOMINA L_SETTING 
SETTING 

SETTING_ERROR ) ) 

(©CLASS* BER_REGISTERS ) 

(©CLASS* GaAsFETS 

(©PROPERTIES* 

DRAINJ/OLTAGE 

gateJvoltage 

NOMINAL_DRAIN_VOLTAGE 
NOMINAL~GATE_VOLTAGE ) ) 

(©CLASS* LOCALOSCILLATORS 

(©PROPERTIES* 

CO MP0NENT_0 UT_2 
FREQUENCY JDUTJ 
NOMINA L_FREQUENCY_OUT_2 
nominal’poweroutj 

POWER_OUT_2 ) ~ ) 


The subclass called amplifiers is used to classify objects that represent 
components that amplify the power level of the signal inside the transponder system. 
Associated with this class are 8 floating point properties. The first two properties listed 
in definition of amplifiers in Code Segment 4.4a are bias_current and bias voltage. 
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These properties represent the bias current and bias voltage supplied to an amplifier 
component by its power supply. The second two properties, drainvoltage and 
gate_voltage are used to represent the voltage levels on an amplifier component’s drain 
and gate respectively. The design parameters specify nominal values for these four 
quantities. The remaining properties, prefixed by nominal_ are used to represent the 
respective parametric values. 

The subclass called attenuators is used to classify objects that represent 
components that attenuate the power level of the signal inside the transponder system. 
Again, several properties are unique to these objects. Attenuator objects have only one 
unique attribute. This is that they have a setting. The levels of attenuation for these 
components are set either manually or by the Network Control Computer (NCC). This 
value is stored in the floating point property called setting. The parametric value for 
an attenuator’s setting is represented by the nominal setting property. The difference 
between an attenuator’s nominal setting and its actual setting is represented by the 
property called setting error. And finally, a remanent of the model-based overhead 
is provided for an attenuators model setting. 

The third definition in Code Segment 4.4a creates a class called berregisters. 
This class is used to represent the Bit Error Rate Register objects as components of the 
transponder system. The roles of sensors as both sensor elements and transponder 
system components were discussed in section 3.1.3 of chapter 3. 

The fourth class definition creates a class for the GaAs FET Amplifier. This 
shares four properties with the amplifiers class. However, the GaAsFETS class is 
separated from the amplifiers because the bias current and bias voltage properties have 
no meaning for Gallium Arsenide Field Effect Transistor (GaAs FET) amplifiers. The 
properties drain _ and gate voltage and their associated nominal_ values for the GaAs 
FETs are the same as for the amplifiers. 
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The final class definition in Code Segment 4.4a creates a classification for the 
objects that represent local oscillators (LO). The localoscillators class has five 
unique properties. However, all of these as extensions of concepts which have already 
been discussed. That is, the local oscillators in the ACTS transponder system are 
multiple output devices. Each unit has one output per channel through the transponder. 
In the current phase of development, only two channels are operating. This requires that 
an additional output port be represented in the properties of the objects that represent 
Los. Therefore, the properties that represent the functional and relational attributes of 
a component’s output port were duplicated and suffixed by _ 2 . 

Code Segment 4.4b continues the definition of the classes which organize the 
components world hierarchy. The first definition creates a class for the objects that 
represent the two multiplexers, or signal mixers. These units have an additional input 
for a signal from a local oscillator. Therefore, the properties for component input 
parameters were duplicated and prefixed with lo_ to represent this additional signal. The 
property lojjnjt corresponds to the componentjn property discussed earlier, except 
that this property represents the name of the local oscillator associated with the LO input 
port. 

The second definition in Code Segment 4.4b creates a class called pwrmeters. 
This class is used to represent the power meter objects as components of the transponder 
system. 

The third definition creates a class called receivers for the objects that represent 
the two receiver components in the transponder. As for the mixers, these components 
also have a LO input port. Therefore, this class has the same properties as the mixers 
class and the corresponding properties represent the same quantities. 
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Code Segment 4.4b: Definition of the COMPONENTS Subclasses 


(©CLASS ~ MIXERS 

(©PROPERTIES = 

LO_INPUT_FREQUENCY 

lo_input"power 
LOJJNIT ~ 

NOMINA LLOINPUTFREQUENCY 
NO MINA L~LO_INPUT~PO WER ) ) 

(©CLASS » POWER^METERS ) 

(©CLAS S= RECEIVERS 

(©PROPERTIES “ 

LOINPUTFREQUENCY 
LOINPUTPOWER 
LO_UNIT ~ 

NOMINALLOJNPUTFREQUENCY 
NOMINA L~LO~INPUT~PO WER ) ) 

(©CLASS = SWITCHES 

(©PROPERTIES = 

COMPONENT_IN_2 

COMPONENT~OUT_2 

FREQUENCY^ 

FR£QUENCY~IN_2 

FREQUENCY~OUT_2 

GAIN_2 

MOD EL_G A IN_2 

model"power_in_2 

model”power~out_2 

nominal_frequency_2 

NOMINAL_FREQUENCYJN_2 
NOMINAL~FREQUENCY_OUT_2 
NOMINA L~GAIN_2 

nominaljwerjn2 

nominal”power^out_2 

POWER_INJ 

POWER~OUT_2 ) ) 

(©CLASS = TWTAS ) 


The fourth class definition in Code Segment 4.4b creates a class for the matrix 
switch. This component is a multiple input/output device having one input and one 
output per channel in the transponder system. Since there are two channels, one 
additional input and one additional output port needed to be represented in the properties 
of the switches class. Again, these are simply extensions of concepts discussed for the 
general case of components , and they are suffixed by _2. 
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The final class definition for the subclasses of the components world is twtas. 
This class is for the Traveling Wave Tube Amplifier (TWTA). There are no unique 
properties associated with this component. 

4.1.3 Object Definitions 

The next step is to create objects to represent the various components of the 
transponder system and link them to their respective component type subclasses. These 
definitions are given in Code Segments 4.5a and 4.5b. Each object corresponds to one 
of the transponder system components that were introduced in section 1.1.2 of chapter 
1 . They are listed in Table 1.1. 

The first definition in Code Segment 4.5a creates an object to represent the 
Gallium-Arsenide Field Effect Transistor (GaAs FET) amplifier. This unit is located at 
the output of the channel 1 signal path, see Figure 1.2. This object, called caasfet, is 
linked as a child of the GaAsFETS class. Therefore, it inherits all the associated properties 
that were discussed in the previous section. 

The next two definitions create objects to represent the High Power Amplifier 
Input Power Control (HPAPC) amplifiers labeled as E and F in Figure 1.2. hpapc_amp_i 
represents the power control amplifier in the channel 1 output signal path and 
HPAPC AMP 2 represents its counterpart in channel 2. Since both these objects represent 
amplifiers in the transponder, they are both attached to the amplifiers subclass of the 
components hierarchy. 

The remaining HPAPC components are the attenuators labeled as K, L, M, and N 
in Figure 1.2. These components are represented by the objects created as hpapc attnj 
through hpapc a ttn_4. The fourth through seventh definitions in Code Segment 4.5a 
create these objects and attach them to the attenuators class. 
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Code Segment 4.5a: Objects of the COMPONENTS Class 


(©OBJECT- GAASFBT 

(©CLASSES = GaAsFETS ) ) 

(©OBJECT- HPAPC_AMP_1 

(©CLASSES- AMPLIFIERS ) ) 

(©OBJECT** HP A PC_ A MP_2 

(©CLASSES = AMPLIFIERS ) ) 

(©OBJECT- HPAPCATTNJ 

(©CLASSES =* ATTENUATORS ) ) 

(©OBJECT- HP A PC_A TTN_2 

(©CLASSES- ATTENUATORS ) ) 

(©OBJECT- HPA PC_ATTN_3 

(©CLASSES = ATTENUATORS ) ) 

(©OBJECT* HPAPC_ATTN_4 

(©CLASSES* ~ ATTENUATORS ) ) 

(©OBJECT- IFPC_AMP_1 

(©CLASSES- AMPLIFIERS ) ) 

(©OBJECT- IFPC_AMP_2 

(©CLASSES- ~ AMPLIFIERS ) ) 

(©OBJECT- EFPC_AMP_3 

(©CLASSES- ~ AMPLIFIERS ) ) 

(©OBJECT- IFPC_AMP_4 

(©CLASSES- ~ AMPLIFIERS ) ) 

(©OBJECT- IFPC_ATTN_1 

(©CLASSES- ATTENUATORS ) ) 

(©OBJECT- IFPC_ATTN_2 

(©CLASSES- ATTENUATORS ) ) 

(©OBJECT- IFPCATTN3 

(©CLASSES- ~ ATTENUATORS ) ) 

(©OBJECT- IFPC_ATTN_4 

(©CLASSES- " ATTENUATORS ) ) 


The remaining definitions in Code Segment 4.5a create objects to represent the 
Intermediate Frequency Power Control (IFPC) components within the transponder 
system. These were indicated in Figure 1.2 by labels A through J. The first four, 
ifpc_amp_i through _4, represent the IFPC amplifiers. They are therefore linked as 
children of the amplifiers subclass. The remaining four, ifpc_attn_i through j. 
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represent the IFPC attenuators. They are therefore linked as children of the 
ATTENUATORS subclass. 

Code Segment 4.5b continues the definition of objects that represent the 
components of the transponder system. The first two definitions create a new property 
called confjg and an object called mswitch that represents the matrix switch component. 
It is attached as a child of the switches subclass in the components world hierarchy. 
This object has a unique property called config that is used to represent the multiple 
channel handling of the matrix switch. The specifics of this property are discussed in 
the next chapter. 


Code Segment 4.5b: Objects of the COMPONENTS Class 


(©PROPERTY * CONFIG 


©TYPE* 

String;) 


(©OBJECT* MSWITCH 

(©CLASSES* 
(©PROPERTIES - 

SWITCHES 
CONFIG ) 

) 

) 


(©OBJECT = MULTJ 

(©CLASSES = 

MIXERS 

) 

) 


(©OBJECT = MULT_2 

(©CLASSES = 

MIXERS 

) 

) 


(©OBJECT = RCVR_1 

(©CLASS ES = 

RECEIVERS 

) 

) 

(©OBJECT * RCVR_2 

(©CLASSES = 

RECEIVERS 

) 

) 

(©OBJECT* RCVRLO 

(©CLASSES* 

LOCAL_OSCILLATORS 

) 

(©OBJECT* TWTA 

(©CLASSES* 

TWTAS 

) 

) 


(©OBJECT* UPXLO 

(©CLASSES* 

LOCAL_OSCILLATORS 

) 


The next two definitions create objects, mult_1 and mult_2, to represent the up- 
converter multiplexers. These components were indicated in Figure 1 .2 and Table 1 . 1 
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as chi mix and CH2MIX. Both these objects are attached to the mixers subclass of the 
components hierarchy. They therefore inherit all properties that were discussed in the 
previous sections. 

The definitions in Code Segment 4.5b continue with the definition of two objects 
to represent the receiver units at the inputs to the transponder system. The object named 
rcvr i represents the Channel 1 Receiver Unit that was labeled as chircvr in Figure 1.2 
and Table 1.1. The object named rcvr_2 represents the Channel 2 Receiver Unit that 
was labeled as CH2RCVR. Both these objects are attached as children of the receivers 
class discussed in the previous section. 

Objects that represent the local oscillator units in the transponder are created and 
attached to the local_oscillators class. The object called rcvr lo represents the 
Receiver Unit Local Oscillator that drives the receiver units. The object called upx_lo 
represents the Up-converter Mixer Local Oscillator that drives the up-converter mixers. 

Finally, the Traveling Wave Tube Amplifier (TWTA) is represented by the 
creation of an object called twta attached to the twtas subclass. This completes the 
definition of the Class/SubClass/Object hierarchy that was introduced in section 3.1.1 of 
chapter 3. The next section of this chapter discusses the representation of the Subsystems 
Class that was introduced in section 3.1.2 of chapter 3. 

4.2 Representation of Transponder Subsystems 

It was shown in Figure 3.2 how each component of the transponder is associated 
with a subsystem of the transponder. Several object frames are used to represent the 
collections of components called subsystems. These frames are then organized by 
attaching them to a class frame for all subsystems in the transponder. Finally, the 
membership of a component to a particular subsystem is represented by attaching its 
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object frame as a subobject of the appropriate subsystem object frame. The following 
code segments define this hierarchy. 

4.2.1 Property Definitions 

Code Segment 4.6 shows a series of declarations that define the properties which 
are to be used to describe the subsystems of the transponder system. The first property 
is called diagnostic_module. Recall from section 1.3 of the introduction that the idea 
of a transponder subsystem was developed for the isolation of a fault. Once a fault is 
isolated to a subsystem of the transponder, the next step is to load a diagnostic module 
to perform the task of fault diagnosis on that subsystem. This Boolean property is 
initialized to load the diagnostic knowledge base that corresponds to a particular 
subsystem. The details of this are discussed in the following chapter. 


Code Segment 4.6: Properties of the SUBSYSTEMS Class 


(©PROPERTY = 

DIAGNOST1CMODULE 

©TYPE* Boolean;) 

(©PROPERTY- 

ISOLATED 

©TYPE* Boolean;) 

(©PROPERTY* 

LEVEL IN 

©TYPE* String;) 

(©PROPERTY* 

LEVEL_OUT 

©TYPE* String;) 

(©PROPERTY* 

READINOJN 

©TYPE = String ;) 

(©PROPERTY* 

READING_OUT 

©TYPE “String;) 

(©PROPERTY* 

SENSOR JN 

©TYPE* String;) 

(©PROPERTY* 

SENSORJ3UT 

©TYPE* String;) 

(©PROPERTY* 

SUBSYSTEMS 

©TYPE* String;) 

(©PROPERTY* 

SUBSYSTEMOUT 

©TYPE* String;) 


The Boolean property called isolated is used to flag a subsystem as being the 
probable source of a detected fault. The rule knowledge used in isolating a fault is 
discussed in chapter 7. The actions of these rules set this flag to indicate a subsystem 
has been isolated. 
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The next four definitions in Code Segment 4.6 are for string properties to describe 
the signal power levels at the input and output of a subsystem. The reading IN and 
readingjOUT properties are set to the qualitative descriptions, "GOOD" or "bad, ' ascribed 
to sensor readings during the fault detection. The level JN and level_out properties are 
set to the qualitative descriptions, "HIGH," "LOW", "zero," or "OK," that are also ascribed 
to signal power levels during fault detection. 

The remaining definitions create properties to describe structural information 
about the subsystems of the transponder. The string properties sensorin and 
sensor out are initialized to the name of the sensor object at a subsystem’s input and 
output respectively. Similarly, the string properties subsystemin and subsystem our 
are initialized to the name of the subsystem object at a subsystem’s input and output 
respectively. 

4.2.2 Class Definition 

The next definition, Code Segment 4.7, creates a class frame called subsystems 
in the object space of the expert system. The properties discussed in the previous section 
are assigned to this class and are inherited by all attached object frames. 
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Code Segment 4.7: Definition of the SUBSYSTEMS Class 


(©CLASS =* SUBSYSTEMS 

(©PROPERTIES = 

DIAGNOSTIC_MODULE 

ISOLATED 

LEVEL JN 

LEVEL~OUT 

NAME 

READINO_IN 

reading’out 

SENSORIN 

SENSOR_OUT 

SUBSYSTEMS 

SUBSYSTEM_OUT ) ) 


4.2.3 Object Definitions 

There are seven subsystems in the transponder system. Each is represented by 
an object attached as a child of the subsystems class. Code Segment 4.8 lists the 
definition for six of these. 

First, an object is created to represent the Channel 1 Amplifier Subsystem. Its 
object name is chiamp. The GaAs FET amplifier is the only transponder component in 
this subsystem. The object that represents this component, gaasfet, is attached as a 
subobject of the chiamp object. 

Second, the Channel 1 Receiver Subsystem is represented by creating an object 
called chircvr and attaching it to the subsystems class. There are four components in 
this subsystem. The objects which represent these components, ifpc ampj, ifpc attnj, 
rcvrj, and rcvr lo, are attached as subobjects of the chircvr subsystem. 

The object that represents the Channel 1 Up-converter Subsystem is defined in 
Code Segment 4.8 as chiupx. Its subobjects are the hpapc_ampj, hpapc_attnj, 
HPAPCA TTN 2, MULTJ, and UPXLO. 
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Code Segment 4.8: Objects of the SUBSYSTEMS Class 


(©OBJECT- CHI AMP 

(©CLASSES* SUBSYSTEMS ) 

(©SUBOBJECTS * GAASFET ) ) 

(©OBJECT = CH1RCVR 

(©CLASSES- SUBSYSTEMS ) 

(©SUBOBJECTS- IFPC_AMP_1 

IFPC_ATTN_1 
RCVRJ 

RCVR*LO ) ) 

(©OBJECT- CH1UPX 

(©CLASSES- SUBSYSTEMS ) 


(©SUBOBJECTS- HPAPC_AMP_1 
HP A PC_A TTN_ 1 
HP A PC~ATTN~2 


MULTJ 

UPXLO ) ) 

(©OBJECT- CH2AMP 

(©CLASSES- SUBSYSTEMS ) 

(©SUBOBJECTS- TWTA ) ) 

(©OBJECT- CH2RCVR 

(©CLASSES- SUBSYSTEMS ) 

(©SUBOBJECTS- IFPC_AMP_2 

efpc’attnj 

RCVR_2 

rcvr”lo ) ) 

(©OBJECT- CH2UPX 

(©CLASSES- SUBSYSTEMS ) 


(©SUBOBJECTS- HPA PC_AMP_2 
HPAPc”aTTN_3 
HPAPc”aTTN~4 
MULT_2 

UPX_LO ) ) 


Fourth, an object is created to represent the Channel 2 Amplifier Subsystem. Its 
object name is CH2AMP. The Traveling Wave Tube amplifier is the only transponder 
component in this subsystem. The object that represents this component, twta, is 
attached as a subobject of the CH2AMP object. 

Next, the Channel 2 Receiver Subsystem is represented by creating an object 
called CH 2 RCVR and attaching it to the subsystems class. There are four components in 
this subsystem. The objects which represent these components, ifpc_amp_2, ifpcattnj, 
rcvr_2, and rcvr lo, are attached as subobjects of the CH2RCVR subsystem. 
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Finally, the object that represents the Channel 2 Up-converter Subsystem is 
defined in Code Segment 4.8 as cmupx. Its subobjects are the hpapc_amp_2, 

HPAPCATTN3, HPAPC_ATTN_4, MULT_2, and UPXLO. 

The remaining subsystem is the Matrix Switch Subsystem. There are five 
components associated with this subsystem. These are represented by the ifpcampj, 
ifpc_amp_4, ifpc_attn_3, ifpc_attn_4, and mswitch component objects. However, the 
definition of the subsystems objects that represent this group of components differs from 
the previous. 

Recall from section 1.2.2 of the introduction that there are multiple permutations 
through the matrix switch. The interconnectivity through the matrix switch was detailed 
in Table 1.2 in chapter 1. To represent each of these signal paths, four objects are 
required. The definitions for these are given in Code Segments 4.9a and 4.9b. 

These objects are not attached as children of the subsystems class. Rather, they 
are left independent. During run time, two of these objects are dynamically linked to the 
SUBSYSTEMS class. This dynamic attachment is based upon the configuration of the matrix 
switch at the time a diagnostic session begins. The dynamics of this configuration is 
discussed in the next chapter. 

The objects defined in Code Segment 4.9a represent the signal paths through the 
matrix switch subsystem in its primary configuration. This configuration is: Channel 1 
Input routed to Channel 1 Output and Channel 2 Input routed to Channel 2 Output. In 
later discussions, this configuration is referred to as matrix switch configuration a. 



61 


Code Segment 4.9a: Dynamic Objects of the SUBSYSTEMS Class 


(©OBJECT = MSWJTCHCHl 1 

(©SUBOBJECTS = MS WITCH 

IFPC_AMP__3 

ifpc’attnj ) 

(©PROPERTIES = 

DlAGNOSTIC_MODULE 

ISOLATED 

LEVELS 

LEVEL~OUT 

name’ 

READING JN 

readsg’out 

SENSOR _S 
SENSOR* OUT 
SUBSYSTEMS 

SUBSYSTEM~OUT ) ) 

(©OBJECT= MSWITCH_CH22 

(©SUBOBJECTS- MSWITCH 

IFPC_AMP_4 
IFPC~ATTN_4 ) 

(©PROPERTIES = 

DIAGN0STICJ40DULE 

ISOLATED 

LEVEL_IN 

level’out 

NAME 

READING_IN 

READSGOUT 

SENSOR_LN 

sensor’out 

SUBSYSTEM'S 

subsystem’out ) ) 


The objects defined in Code Segment 4.9b represent the signal paths through the 
matrix switch subsystem in its secondary configuration. This configuration is: Channel 
1 Input routed to Channel 2 Output and Channel 2 Input routed to Channel 1 Output. 
In later discussions, this configuration is referred to as matrix switch configuration b. 
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Code Segment 4.9b: Dynamic Objects of the SUBSYSTEMS Class 


(©OBJECT* MS WITCHCH 1 2 

(©subobj ects * 'mswttch 

IFPC_AMP_4 
IFPC~ATTN_4 ) 

(©PROPERTIES* 

DIAGNOSTlC_MODULE 

ISOLATED 

LEVEL_IN 

LEVEL~OUT 

name” 

READINOIN 
READINGOUT 
SENSORJN 
SENSORJDUT 
SUBSY STEM_IN 

subsystem’out ) ) 

(©OBJECT = MSWITCH_CH22 

(©SUBOBJECTS* MS WITCH 

IF PC AMP J 
lF?CJiTnij ) 

(©PROPERTIES* 

DIAGNOSTICMODULE 

ISOLATED 

LEVEL_IN 

LEVEL~OUT 

NAME 

READINGIN 

READING~OUT 

SENSORJN 

SENSOR~OUT 

SUBSYSTEM^ 

SUBSYSTEM~OUT ) ) 


As these frames represent components of the transponder, they are attached to the 
components class structure as well. This linking of component object frames to the 
components world can be interpreted as an Is-A Link. Links to the subsystems world 
represents Part-Of Links. That is, the IFPC Amplifier Is An amplifier and is Part Of the 
Channel 1 Receiver system. 

This approach not only aids the diagnostic tasks, but provides an efficient coding 
approach. Through multiple inheritance, each subsystem component acquires information 
from two parents. One provides information on performance while the other on 


structure. 
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4.3 Representation of Sensory Components 

Two types of sensory elements monitor both the response of the transponder and 
the relayed signal. The first type is signal power level sensors. The other type 
represents the data stream bit error rate (BER) registers located within the ground 
terminal systems. The information used for diagnosis is provided by these sensors. 

This structure is divided into subclasses according to the two types of sensors. 
Each sensor is then represented by an object attached to the appropriate type subclass. 
The following code segments create this structure in the object space of the expert 
system. 

4.3.1 Property Definitions 

Properties are defined in Code Segment 4.10 to describe the data reported by a 
sensor, its nominal value, the corresponding error, and the tolerance band of 
acceptable error magnitudes. A string property called reading is used for the qualitative 
descriptions which were introduced in section 1.3. 

The string property level is used for a qualitative description of the signal power 
level reported by a sensor. This property is very important to the modules which 
perform diagnostics on the individual subsystems of the transponder. Its utility is 
discussed in great detail in subsequent chapters. However, the floating point property 
zero level is associated with this qualitative description. This property value is 
initialized to the sensor reading below which the sensor can be assumed to be reporting 
a * Zero " value. 
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Code Segment 4 . 10 : Properties of the SENSORS Class 


(©PROPERTY* 
(©PROPERTY = 
(©PROPERTY = 
(©PROPERTY = 
(©PROPERTY* 
(©PROPERTY = 
(©PROPERTY* 
(©PROPERTY* 
(©PROPERTY* 
(©PROPERTY* 
(©PROPERTY* 
(©PROPERTY* 


DATA 

ERROR 

EVALUATED 

LEVEL 

NOMINAL 

READING 

RTN_LEVEL 

RTN~NOMINAL 

RTN_READING 

TOLERANCE 

TYPE 

ZERO_LEVEL 


©TYPE* Float;) 
©TYPE* Float;) 
©TYPE* Boolean;) 
©TYPE* String;) 
©TYPE* Float;) 
©TYPE* String;) 
©TYPE* Boolean;) 
©TYPE* Boolean;) 
©TYPE* Boolean;) 
©TYPE* Float;) 
©TYPE* String;) 
©TYPE* Float;) 


Once a sensor has been evaluated, a Boolean property called evaluated is set to 
true. This property is used to poll a sensor to determine if its reported sensor data has 
been evaluated. A value of true implies that the current descriptions of reading and 
level reflect the current reported data value. 

The remaining properties for sensors class are those required by the ToolBook" 
Graphical User Interface (GUI). The string property type is used to communicate the 
type of sensor, m BER m or *PM, m which is communicating information to the GUI. The 
other properties, prefixed with rtn_, are used to initiate communication of sensor level 
and reading descriptions as well as nominal sensor data values through the GUI. 

4.3.2 Class Definitions 


The sensors class hierarchy was introduced in chapter 3. The definitions which 
create the structure shown in Figure 3.3 are given in Code Segment 4.11. 
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Code Segment 4.11: SENSORS Class Hierarchy 


(©CLASS- SENSORS 

(©SUBCLASSES- 

FWRSENSORS 

berJsensors ) 

(©PROPERTIES — 



DATA 

ERROR 

EVALUATED 

LEVEL 

NAME 

NOMINAL 

READING 


RTNLEVEL 


RTN_NOMINAL 


RTN~READING 


TOLERANCE 

TYPE 


ZERO_LEVEL 

(©CLASS- 

PWR_SENSORS 

(©CLASS- 

BERJ5ENSORS 


(©SUBCLASSES- 

CH1_BER» 

CH2~BERs ) ) 

(©CLASS- CHl_BERs ) 

(©CLASS- CH2_BER» ) 

(©CLASS- BAD_SENSORS 

(©properties'- RTN^READINO ) ) 


The first definition creates the sensors class in the object space of the FIDEX 
system. This definition attaches two subclasses to the sensors frame. The class called 
pwr_sensors is used to classify objects which represent signal power level sensors. The 
second class, called berjensors is used to classify objects which represent data stream 
bit error rate registers. The remainder of the definition for the sensors class attaches 
the properties discussed in the previous section to this hierarchy. 

Notice that the string property name is also associated with the sensors class. 
This property was defined with the components class and was therefore not redefined 
in Code Segment 4. 10. This property is used in the same context with sensors as it was 
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for components. It allows sensor objects to post their names in blackboard property 
values and communicate with other objects and generic rules. 

The next two definitions in Code Segment 4.11 create the classes pwrjensors 
and ber sensors in the object space of the FIDEX system. The ber sensors class is also 
divided into two subclasses according to their channel; chi bers and CH2_BERs. This was 
done to simplify the analysis of frequency dependant fault states. It also demonstrates 
how class structures can be cascaded to further describe component function and 
organization. The fourth and fifth definitions create these classes. 

The final definition is Code Segment 4.11 creates a class called bad_sensors. 
This class is used as a list of sensors which report ' bad - sensor readings. This class is 
not a sensors subclass, but it is associated with the sensors world. The only property 
used in connection with this class is the rtn_reading property. This is required to return 
a list of the sensors evaluated as having "BAD" readings to the GUI. 

4.3.3 Object Definitions 

Each sensory component is represented by an object frame. These frames are 
linked to their appropriate type subclass in both the components world, and the sensors 
world. The definitions which create objects to represent sensory components are given 
in Code Segments 4.12a and 4.12b. Code Segment 4.12a lists the definitions for the 
BER registers, berj, ber_2, and berj are associated with the channel 1 user data 
stream. They are therefore attached to the sensors hierarchy as chi bers. ber_4, ber_s, 
and BER_6 are associated with the channel 2 user data stream. They are therefore 
attached to the sensors hierarchy as CH2_BERs. 

Like all other transponder components, sensory dements could potentially fail. 
Therefore, each BER sensor is also represented FIDEX as a member of the component 



67 


world; belonging to the class of ber_registers that was discussed in section 2.3 and 
section 4.1. 


Code Segment 4 . 12 a: BER_SENSOR Objects 


(©OBJECT- BERJ 

(©CLASSES- 

CHl_BERi 

BER~REGISTERS ) ) 

(©OBJECT = BERJ 

(©CLASSES — 

CHlJERi 

BER~REGISTERS ) ) 

(©OBJECT — BERJ 

(©CLASSES- 

CHIBERs 

BER~REG1STERS ) ) 

(©OBJECT = BERJ 

(@CLASSES = 

CH2_BERi 

ber'registers ) ) 

(©OBJECT = BERJ 

(©CLASSES- 

CH2_BERi 

BER~REGISTERS ) ) 

(©OBJECT = BERJ 

(©CLASS ES= “ 

CH2_BERi 

BER~REG1STERS ) ) 


Code Segment 4.12b lists the definitions for the signal power level sensors. 
These eight sensors were listed in Table 1.1. The objects which represent pmj through 
pm 8 are attached to the sensors hierarchy at the pwr_sensors node. To represent their 
role as transponder components which could potentially fail, each signal power level 
sensor is also represented FIDEX as a member of the component world; belonging to the 
class of power_meters. 
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Code Segment 4.12b: PWR_SENSOR Objects 


(©OBJECT- PM [J 

(©CLASSES = 

POWER_METERS 
PWRSENSORS ) ) 

(©OBJECT- PM_2 

(©CLASSES- 

POWER_METERS 
PWRJENSORS ) ) 

(©OBJECT- PMJ 

(©CLASSES - 

POWER_METERS 
PWRSENSORS ) ) 


(©OBJECT- PM_4 

(©CLASSES- 

POWERJvfETERS 
PWRSENSORS ) ) 

(©OBJECT- PMJ 

(©CLASSES- 

POWER_METERS 
PWRSENSORS ) ) 


(©OBJECT- PMJ 

(©CLASSES =~ 

POWER_METERS 
PWRSENSORS ) ) 

(©OBJECT- PM J 

(©CLASSES- 

POWER_METERS 
PWRSENSORS ■) ) 


(©OBJECT- PMJ 

(©CLASSES- 

POWER_METERS 
PWRJENSORS ) ) 


4.4 Representation of Fault States 

The transponder fault states are represented as objects in a class structure called 
fault states. This class is also divided into several subclasses. Each subclass frame 
represents the association of fault states to component types; such as amplifier faults, 
attenuator faults, etc. Object frames representing the specific failure modes of the 
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transponder are then attached to the appropriate subclasses. This structure enables 
FIDEX to reason about both known and abstract faults. 

The code segment which defines this structure is nearly identical to that of the 
components class. This is because the types of fault states are associated with the types 
of components. 

4.4.1 Property Definitions 

The properties associated with the fault_states class are listed in the next code 
segment. These describe which component the fault is associated with, its iNFeRence 
CATEGORY or priority, and the power symptom group with which is associated. A 
Boolean property, verified, is used to flag fault states which have been verified by the 
diagnostic process. The final property listed is Value. This property is a reserved by 
NEXPERT". The fault states represent the hypotheses of rules used during diagnosis. 
This property is assigned the results of rule evaluations. 


Code Segment 4.13: Properties of the FAULTJSTATES Class 


(©PROPERTY* 
(©PROPERTY* 
(©PROPERTY = 
(©PROPERTY * 
(©PROPERTY = 


COMPONENT ©TYPE* String;) 

INFCAT ©TYPE* Float;) 

POWERSYMPTOMGROUP ©TYPE* String;) 
Value * ~ ©TYPE* Special;) 

VERIFIED ©TYPE* Boolean;) 


In chapter 3, the certainty _analysis class was introduced. This is a superclass 
of the fault states class. It is used to define the overhead required for inexact and 
abstract reasoning; as discussed in section 3.3. Code Segment 4.14 gives the definition 
of properties required for the certainty _analysis superclass. 



70 


Code Segment 4.14: Properties of the CERTAINTY '_ANALYSIS Class 


(©PROPERTY = AB @TYPE=Flo*t;) 

(©PROPERTY = AD @TYPE=Fk»t;) 

(©PROPERTY = CF ®TYPE=Fk»t;) 

(©PROPERTY m CONFIDENCE @TYPE=Slring;) 

(©PROPERTY = MB ©TYPE = Flo* t;) 

(©PROPERTY = MD ®TYPE=Flo»t;) 


Five floating point properties are used to represent each quantity in the MYCIN 
equations. The current measures of belief and disbelief are represented by the mb and 
md properties. The accumulated belief and disbelief are represented by the ab and ad 
properties. Finally, the overall confidence is represented by the cf property. A string 
property called confidence is used for a qualitative description of confidence. 


4.4.2 Class Definitions 


The definitions for classes in the fault_states hierarchy are given in the 
remaining code segments. First, the definition in Code Segment 4.15 creates the 
superclass for certainty analysis. The fault states class is attached as a subclass, and 
the properties discussed above are defined with this class. 


Code Segment 4.15: Definition of CERTAINTY ^ANALYSIS Class 


(©CLASS = CERTA INTYANALYS IS 

(©SUBCLASSES = FAULT_STATES ) 

(©PROPERTIES = 

AB 

AD 

CF 

CONFIDENCE 

MB 

MD ) ) 
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Code Segment 4.16 defines the class for fault jtates in the object space of the 
FIDEX system. The properties in Code Segment 4.13 are assigned and class for each 
type of fault state attached as subclasses. The definitions for the classes which represent 
these fault state types are given in Code Segment 4.17. 


Code Segment 4.16: Definition of the FAULT^STATES Class 


(©CLASS- FA ULT_ST ATES 

(©SUBCLASSES =~ 

AMPLIFIERFAULTS 
ATTENUATOR_FAULTS 
GaAi_FET_ FAULTS 
LO_ FAULTS 
MIX ER_F AULTS 
RECEIVERF AULTS 
SWITCH_F AULTS 
TWTA FAULTS ) ) 


Each class defined in Code Segment 4. 17 represents an association of a fault state 
with a type of transponder component. The class called amplifier_faults is used to 
classify all fault states associated with amplifier components. The class called 
attenuator faults is used to classify all fault states associated with attenuator 
components. The class called GaAs_FET_FAULTS is used to classify all fault states 
associated with GaAsjET components. The class called LO faults is used to classify all 
fault states associated with localjoscillator components. The class called 
mixer faults is used to classify all fault states associated with mixer components. The 
class called receiver j aults is used to classify all fault states associated with receiver 
components. The class called switch_faults is used to classify all fault states associated 
with switch components. And finally, the class called twta faults is used to classify 
all fault states associated with twta components. 
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Code Segment 4*17: Subclasses of the FA ULT_STA TES Hierarchy 


(©CLASS = 

AMPLIFIERFAULTS 

) 

(©CLASS* 

ATTENUATOR_FAULTS 

) 

(©CLASS = 

GaA«_FET_FAULTS ) 


(©CLASS* 

LO_FAULTS ) 


(©CLASS* 

MDCERFAULTS ) 


(©CLASS - 

RECEIVER_FAULTS ) 


(©CLASS* 

SWITCH_FAULTS ) 


(©CLASS* 

TWTA_FAULTS ) 



The discussion of the objects which represent the fault states in this hierarchy is 
presented in later chapters. As each diagnostic module is presented, the fault states 
associated with that subsystem are discussed. 


CHAPTER V 

FEDEX KERNEL KNOWLEDGE BASE 


This chapter continues discussion on the kernel of the frame-based knowledge of 
the FIDEX system. The previous chapter discussed the definition of classes, objects, and 
properties to represent the structure, operation, and fault states of the ACTS transponder 
system. In this chapter, the object dynamics of the FIDEX. tkb knowledge base are 
discussed. 

5.1 Inference Strategies 

The first topic of importance is the definition of the global inheritance and 
inference strategies used by the FIDEX system, see Code Segment 5.1. The first two 
definitions establish the global strategy for value inheritance within frame hierarchies. 
Upward value inheritance is disabled and downward value inheritance is enabled. 

The next two definitions establish the inheritance strategies for property 
inheritance within an object/subobject hierarchy. These are only included for 
completeness. There is no property inheritance in the object/ subobject hierarchies within 
the FIDEX system. All such inheritances, both upward and downward, are disabled. 

The fifth and sixth definitions establish inheritance strategies within class 
hierarchies. As for the value inheritance, class properties are inherited downward only. 
The seventh definition in Code Segment 5.1 enables breadthwise inheritance through a 
lattice of hierarchies. This definition is very important. NEXPERT”’s default setting 
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for this global is false. It must be set to true for the lattice structure of the FIDEX 
system to function properly. The eighth definition disables parent-to-child inheritance 
during run time. Setting this global to false enables class level properties to be assigned 
values which are not inherited by its child objects. The importance of this is elaborated 
upon in the discussion of abstract fault states. 


Code Segment 5.1: Global Inference Strategy Definitions 


(^VERSION » 020) 

<<3<3LOBALS = (3INHVALUP = FALSE; 

(3INHVALDOWN = TRUE; 
<3INHOBJUP= FALSE; 
©INHOBJDOWN = FALSE; 
@INHCLASSUP= FALSE; 
©INHCLASSDOWN =TRUE; 
(3INHBREADTH =TRUE; 

(3 INHPA RENT = FALSE; 
<3PWTRUE=TRUE; 
<3PWFALSE=TRUE; 
©PWNOTKNO WN * TRUE; 
(3EXHBWRD =TRUE; 
<3PTGATES=TRUE; 
<3PFACTIONS*TRUE; 
@SOURCESON = TRUE; 
<3CACTIONSON=TRUE; ) 


The next six definitions establish the global strategy for propagation of 
inferencing. These definitions are changed periodically by certain methods. However, 
this global strategy is maintained throughout most of the knowledgebase. To enable 
foreword chaining, full propagation is required. Therefore, propagation while true, 
false, arid notknown are enabled. Since foreword chaining in NEXPERT" is 
accomplished through a mechanism called gating, propagation through gates must also 
be enabled. And finally, since many foreword chaining strategies are initiated from 
meta-slot actions, propagation from actions must also be enabled. The exhaustive 
backward strategy is enabled to allow foreword actions to evaluate contexts in which one 
hypothesis is supported by multiple rules. 
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The final two definitions in Code Segment 5.1 enable the order-of-sources (OS), 
(©sources-...), and if-change (IC) actions, (©cactions=...), within property slots. These 
are fundamental to the performance of the FIDEX system. Both must be set to true. 

5.2 Initialization of Object/Class Parameters 

The values of many of the properties introduced in chapter 4 represent constant 
quantities. Such properties are those used to represent object names, input/output 
parameters, and nominal parameter values. This section discusses the initialization of 
these properties using both hard-coded and dynamic assignments. 

Property values can be initialized through it meta-slots in two manners. The 
FIDEX kernel knowledge base uses both of these. The first way to initialize a property 
value is by using the initial value, (@initval=...), definition within a slot definition. 
When this method is used, the value of the slot is initialized to the defined value during 
the initialization of the knowledge base. 

The second method is to include a run time value directive in the OS of the slot 
that is associated with an object or class property. This directive provides the sources 
for a constant value during the run time of the inference process. 

5.2.1 Initialization of COMPONENTS Parameters 

The properties associated with the components class were introduced in section 

4.1 and defined in Code Segment 4.1. Several of these provide information on the 
structure of the transponder system or nominal values for other component parameters. 
Specifically, these properties are component _in, componentjout. description, name, 
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NASAJD, as well as the nominal_ values for frequency, frequency jn, frequency_out, 
gain, power in, and POWER out. 

Names of Component Objects 

The slot definitions for initializing the name of components objects are given in 
Code Segments 5.2a through 5.2c. These definitions initialize the NAME property of each 
object that represents components of the transponder system. Both initial value and run 
time value techniques are used. 


Code Segment 5.2a: Initialization of < j COMPONENTS j >.NAME 


(©SLOT- GAASFET.NAME 

(©INITVAL- ’GAASFET’) 

(©SOURCES- (RunTime Value (■GAASFET’)) ) ) 

(©SLOT- HPAPC_AMP_1 .NAME 

(©INITVAL- *HPAPC_AMP_1 ’) 

(©SOURCES- (RunTimeValue ("HPAPCAMPl ")) ) ) 

(©SLOT- HPAPC_AMP_2.NAME 

(©INITVAL- ’HPAPC_AMP_2’) 

(©SOURCES- (RunTimeValue (’HPAPC_AMP_2*)) ) ) 

(©SLOT- HPAPC_ATTN_1 .NAME 

(©INITVAL- ’ H P APC_ATTN_ 1 ') 

(©SOURCES- (RunTimeValue ("HPAPC_ATTN_1 ’)) ) ) 

(©SLOT- HPAPC_ATTN_2.NAME 

(©INITVAL- ' HPAPC_ATTN_2’) 

(©SOURCES- (RunTimeValue (’HPAPC_ATTN_2’)) ) ) 

(©SLOT- HPAPC_ATTN_3.NAME 

(©INITVAL- ’ HP APC_ATTN_3 ") 

(©SOURCES- (RunTimeValue (’HPAPC_ATTN_3’)) ) ) 

(©SLOT- HPAPC_ATTN_4.NAME 

(©INITVAL- ’HPAPC_ATTN_4") 

(©SOURCES- (RunTimeValue ("HPAPC_ATTN_4")) ) ) 
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Code Segment 5.2b: Initialization of < | COMPONENTS \ >.NAME 


(©SLOT- IFPC_AMP_1 .NAME 

(@INITVAL= ” *ffPC_AMP_1’) 

(©SOURCES — (RunTimeValue (‘IFPC_AMP_1 ")) ) ) 

(©SLOT- IFPC AMP_2.NAME 

(©INITVAL- " *IFPC_AMP_2') 

(©SOURCES- (RunTimeVilue ("IFPC_AMP_2')) ) ) 

(@SIX)T= IFPC_AMP_3 .NAME 

(©INITVAL- ’DFPC_AMP_3‘) 

(©SOURCES = (RunTimeValue (’IFPC_AMP_3*)) ) ) 

(@SLOT= IFPC_AMP_4.NAME 

(©INITVAL- ' IFPC_ AM P_4 ’) 

(©SOURCES = (RunTimeValue ('IFPC_AMP_4")) ) ) 

(@SLOT= IFPC_ATTN_1 .NAME 

(@INITVAL= ’ IFPC_ATTN_1 ”) 

(©SOURCES = (RunTimeValue ('IFPC ATTN l')) ) ) 

(@SLOT= IFPC_ATTN_2.NAME 

(@INITVAL= ”IFPC_ATTN_2') 

(©SOURCES = (RunTimeValue ("IFPC_Al 1N_2")) ) ) 

(@SLOT= IFPC_ATTN_3.NAME 

(@INITVAL= ' IFPC_ATTN_3 ') 

(©SOURCES = (RunTimeValue ('IFPC_ATTN_3')) ) ) 

(@SLOT= IFPC_ATTN_4 .NAME 

(@tNITVAL= "IFPC_ATTN_4") 

(©SOURCES = (RunTimeValue (‘IFPC_ATTN_4*)) ) ) 

(@SLOT= MS WITCH. NAME 

(QINTTVAL- -MS WITCH’) 

(©SOURCES = (RunTimeValue (’MSWITCH’)) ) ) 

(©SLOT= MUL.T_1.NAME 

(@tNITVAL= ’MULT_1 ’) 

(©SOURCES = (RunTimeValue ("MULT_I’)) ) ) 

(©SLOT- MULT_2.NAME 

(©INITVAL— ’MULT_2’) 

(©SOURCES— (RunTimeValue ("MULT_2“» ) ) 

(©SLOT = RCVRl .NAME 

(©INITVAL- ~ ’RCVR_T) 

(©SOURCES- (RunTimeValue (-RCVR_1*)) ) ) 

(©SLOT- RCVR_2.NAME 

(©INITVAL- ” ’RCVR_2") 

(©SOURCES- (RunTimeValue (*RCVR_2’)) ) ) 

(©SLOT- RCVRLO.NAME 

(©INITVAL- ~ "RCVR_LO”) 

(©SOURCES- (RunTimeValue (’RCVRLO’)) ) ) 
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Code Segment 5.2c: Initialization of < | COMPONENTS | >.NAME 


(@SLOT= TWTA.NAME 

(@INITVAL= TWTA-) 

(©SOURCES « (RunTime Value ("TWTA')) ) ) 

(@SLOT= UPX_LO.NAME 

(®INITVAL= ~ ■UPX_LO') 

(©SOURCES = (RunTime Value ("UPXJX)’)) ) ) 


Descriptions of Component Objects 


The slot definitions for initializing the descriptions of components objects are 
given in Code Segments 5.2a through 5.2c. These definitions initialize the description 
property of each object that represents components of the transponder system. 

Code Segment 5.3a: Initialization of < } COMPONENTS | > .DESCRIPTION 


(© S LOT = G AAS FET . D ESCRIPTIO N 

(©INITVAL™ "Gallium- Arsenide Field Effect Transistor Amplifier") 

(©SOURCES™ (RunTimeValue ("Gallium- Arsenide Field Effect Transistor Amplifier")) )) 

(©SLOT™ HPAPC_AMPJ .DESCRIPTION 

(©INITVAL™ "Channel 1 HPAIPC Driver Amplifier") 

(©SOURCES = (RunTimeValue ("Channel 1 HPAIPC Driver Amplifier")) ) ) 

(©SLOT = HPAPC_AMP_2. DESCRIPTION 

(©INITVAL™ "Channel 2 HPAIPC Driver Amplifier") 

(©SOURCES ™ (RunTimeValue ("Channel 2 HPAIPC Driver Amplifier")) ) ) 

(©SLOT™ HPAPC_ATTN J .DESCRIPTION 

(©INITVAL™ "Channel 1 High Power Amplifier Input Attenuator") 

(©SOURCES » (RunTimeValue ("Channel 1 High Power Amplifier Input Attenuator")) )) 

(©SLOT™ HPAPC_ATTN_2. DESCRIPTION 

(©INITVAL™ " "Channel 1 HPAIPC Driver Input Attenuator") 

(©SOURCES ™ (RunTimeValue ("Channel 1 HPAIPC Driver Input Attenuator")) ) ) 

(©SLOT ™ HPAPC_ATTN_3 .DESCRIPTION 

(©INITVAL™ " "Channel 2 HPAIPC Driver Input Attenuator") 

(©SOURCES = (RunTimeValue ("Channel 2 HPAIPC Driver Input Attenuator")) ) ) 

(©SLOT™ HPAPC_ATTN_4. DESCRIPTION 

(©INITVAL™ "Channel 2 High Power Amplifier Input Attenuator") 

(©SOURCES™ (RunTimeValue ("Channel 2 High Power Amplifier Input Attenuator")) )) 
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Code Segment 5.3b: Initialization of < | COMPONENTS\ > .DESCRIPTION 


(©SLOT* IFPC_AMP_1 .DESCRIPTION 

(©INITVAL* "Channel 1 Matrix Switch Input IF PC Amplifier’’) 

(©SOURCES* (RunTime Value ("Channel 1 Matrix Switch Input IFPC Amplifier")) ) ) 

(©SLOT* IFPC_ AM P_2 . DESCRIPTION 

(©INITVAL* "Channel 2 Matrix Switch Input IFPC Amplifier") 

(©SOURCES* (RunTime Value ("Channel 2 Matrix Switch Input IFPC Amplifier")) ) ) 

(©SLOT* IFPC_AMP_3. DESCRIPTION 

(©INITVAL* "Channel 1 Up-converter Input IFPC Amplifier") 

(©SOURCES* (RunTime Value ("Channell Up-converter Input IFPC Amplifier")) ) ) 

(©SLOT* IFPC_AMP_4 .DESCRIPTION 

(©INITVAL* "Channel 2 Up-converter Input IFPC Amplifier") 

(©SOURCES* (RunTime Value ("Channel 2 Up-converter Input IFPC Amplifier")) ) ) 

(©SLOT* IFPC_ATTN_1 .DESCRIPTION 

(©INITVAL* "Channel 1 Matrix Switch Input IFPC Attenuator") 

(©SOURCES* (RunTime Value ("Channell Matrix Switch Input IFPC Attenuator")) ) ) 

(©SLOT* IFPC_ATTN_2. DESCRIPTION 

(©INITVAL* "Channel 2 Matrix Switch Input IFPC Attenuator") 

(©SOURCES* (RunTime Value ("Channel 2 Matrix Switch Input IFPC Attenuator")) ) ) 

(©SLOT = IFPC_ATTNJ .DESCRIPTION 

(©INITVAL* "Channel 1 Up-converter Input IFPC Attenuator") 

(©SOURCES* (RunTime Value ("Channel 1 Up-converter Input IFPC Attenuator")) ) ) 

(©SLOT* IFPC_ATTN_4. DESCRIPTION 

(©INITVAL* "Channel 2 Up-converter Input IFPC Attenuator") 

(©SOURCES* (RunTime Value ("Channel 2 Up-converter Input IFPC Attenuator")) ) ) 


(©SLOT* MSWITCH. DESCRIPTION 

(©INITVAL* "Ford Matrix Switch") 

(©SOURCES* (RunTimeValue ("Ford Matrix Switch")) ) ) 

(©SLOT* MULTJ .DESCRIPTION 

(©INITVAL* "Channel 1 Up-converter Mixer") 

(©SOURCES* (RunTimeValue ("Channel 1 Up-converter Mixer")) ) ) 

(©SLOT* MULT_2.DESCRIFT10N 

(©INITVAL* "Channel 2 Up-converter Mixer") 

(©SOURCES = (RunTimeValue ("Channel 2 Up-converter Mixer")) ) ) 

(©SLOT* RCVR _1 .DESCRIPTION 

(©INITVAL* "Channel 1 Receiver Unit") 

(©SOURCES* (RunTimeValue ("Channel 1 Receiver Unit")) ) ) 

(©SLOT* RCVR2. DESCRIPTION 

(©INITVAL* "Channel 2 Receiver Unit") 

(©SOURCES* (RunTimeValue ("Channel 2 Receiver Unit")) ) ) 

(©SLOT = RCVRLO .DESCRIPTION 

(©INITVAL* "Receiver Units Local Oscillator”) 

(©SOURCES* (RunTimeValue ("Receiver Units Local Oscillator")) ) ) 
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Code Segment 5,3c: Initialization of < \ COMPONENTS\ > .DESCRIPTION 


(©SLOT— TWT A. DESCRIPTION 

(©PIERCED * 3 Traveling Wave Tube Amplifier") 

(©SOURCES = (Pierced (Traveling Wave Tube Amplifier’)) ) ) 

(©SLOT= PERSU AD E_LO. DESCRIPTION 

(©PIERCED = "Up-converter Mixer Units Local Oscillator") 

(©SOURCES 3 * (Pierced ("Up-converter Mixer Unita Local Oscillator")) ) ) 


Retrieval of Remaining Property Values from Database 

Only the values of properties for NAME and DESCRIPTION were hard-coded into the 
frame structure of the components world. The values for the remainder of the 
initialized properties are retrieved from COMPONT.nxp database. This database is 
included in section A. 2 of Appendix A. Code Segments 5.4a through 5.4c give the 
definitions for OS slot actions which retrieve these values. The source actions for each 
of these slots are identical. Therefore, only the first slot definition in Code Segment 5.4a 
are discussed. 

Whenever the value any of these properties for an object in the components class 
is unknown, it is retrieved from a database. The first argument of the retrieve directive 
defines the name of the database to retrieve from. The type, or format, of the database 
is set to the NEXPERT” DataBase type. Forward chaining is disabled so that changes 
to these property values do not affect the agenda. And, the retrieve unknown is set 
active; enabling unknown values to be retrieved from the database. 
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Code Segment 5.4a: Slot Actions to Retrieve & Initialize Properties of COMPONENTS Class 


(@SLOT= COMPONENTS .COMPONENT_IN 

(©SOURCES- (Retrieve CCOMPONT.nxp’) ' 

(©TYPE = NXPDB; V 

@FWRD = FALSE; ' 

©UNKNOWN-TRUE; ' 

©PROPS = NAME, COMPONENTJN, COMPONENT_OUT, NASAID, \ 

NOMINAL_FREQUENCY, NOMINAL_FREQUENCY_IN, \ 

NOMIN AL_FREQUENCY_OUT, NOmIn AL_G AIN, \ 

NOMINAL_POWER_IN, NOMIN AL_POWER_OUT; \ 

©FIELDS- "NAME", ■COMPONENTJN", 'COMPONENT OUT', ’NASA ID', \ 
"NOM_FREQ", ’NOM FREQ_IN*, ’NOM_FREQ_OUT’, \ 

*NOM_GAIN’, *NOM j*OWER_IN*, *NOM_POWER_OUT"; \ 

©ATOMS -SELF;)) ) ) 

(©SLOT- COMPONENTS .COMPONENT_OUT 

(©SOURCES- (Retrieve CCOMPONT.nxp’) ' 

(©TYPE- NXPDB; V 

©FWRD- FALSE; v 

©UNKNOWN -TRUE; v 

©PROPS = NAME, COMPONENT_IN, COMPONENT_OUT, NASA ID, \ 

NOMINAL_FREQUENCY, NOMINAL_FREQUENCY_IN, \ 

NOMINAL_FREQUENCY_OUT, N OM IN AL_G AIN , \ 

NOMINALPOWER IN, NOMIN ALPOWERO UT ; \ 

©FIELDS- ‘NAME’” *COMK)NENT_IN*, ’COMPONENT OUT’ , ’NASA_ID\\ 
■NOM_FREQ’, "NOM FREQ_IN\ ’NOM_FREQ_OUT", \ 

*NOM_GAIN*, ’NOM~POWER_IN’, -NOM_POWER_OUT’; \ 

©ATOMS -SELF;)) ) ) 


(©SLOT- COMPONENTS. NASA_ID 

(©SOURCES- (Retrieve CCOMPONT.nxp*) ' 

(©TYPE- NXPDB; ' 

©FWRD -FALSE; V 

©UNKNOWN -TRUE; ' 

©PROPS-NAME, COMPONENT_IN, COMPONENT OUT, NASA_ID, \ 

NOMIN AL_FREQUENCY, NOMIN AL_FREQUENCY_IN, \ 

NOMIN AL~FREQUENCY_OUT, NOMIN ALGAIN, \ 

NOMINAL POWER_IN, NOMIN AL_POWER_OUT; \ 

©FIELDS- "NAME - ” *COMPONENT_IN’, *COMPONENT_OUT“, *NASA_ID’,\ 
*NOM FREQ", ’ N OM_FREQ_IN " , *NOM_FREQ_OUT" , \ 

’NOM~GAIN’, ’NOM~POWER_IN*, *NOM_POWER_OUT“ ; \ 

©ATOMS -SELF;)) ) ) 


(©SLOT- COMPONENTS.NOMINAL_FREQUENCY 

(©SOURCES- (Retrieve CCOMPONT.nxp*) ' 

(©TYPE- NXPDB; ' 

©FWRD -FALSE; ' 

©UNKNOWN -TRUE; x 

©PROPS = NAME, COMPONENT_IN, COMPONENT.OUT, NASA_ID, \ 

NOMINAL FREQUENCY, NOMIN AL FREQUENCY IN, \ 

NOMIN AL~FREQUENCY_OUT, NOMIN AL_GAIN, \ 

NOMIN AL~POWER IN, NOMIN AL_POWER_OUT; \ 

©FIELDS- ’NAME", ’COMPONENtjN*, *CC>MPONENT_OUT*, ’NASA_ID’,\ 
*NOM FREQ*, ’NOMJTtEQJN*, *NOM_FREQ_O UT '. ' 

’NOMJ3AIN’, ’ N OM J“0 WERIN * , *NOM_POWER_OUT*; \ 

©ATOMS -SELF;)) ) ) 
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Code Segment 5.4b: Slot Actions to Retrieve & Initialize Properties of COMPONENTS Class 


(@SLOT= COMPONENTS ,NOMINAL_FREQUENCYJN 

(©SOURCES = (Retrieve ('COMPONT.nxp') ' 

(©TYPE- NXPDB; ' 

©FWRD- FALSE; ' 

©UNKNOWN -TRUE; ' 

©PROPS -NAME, COMPONENT_IN, COMPONENTOUT, NASA_ID, \ 

NOMINAL FREQUENCY, NOMINAL_FREQUENCY_IN, \ 

NOMIN AL”FREQUENCY_OUT, NOMINALGAIN, \ 

NOMIN AL~POWER_IN, NOMINAL_POWER_OUT; \ 

©FIELDS = ’NAME"” 'COMPONENTIN', ’CC>MPONENT_OUT' , "NASA_ID', \ 
'NOM FREQ", *NOM_FREQ_IN', 'NOM_FREQ_OUT', \ 

'NOMJ3AIN', •NOM~POWER_IN’, 'NOM_POWER_OUT'; \ 

©ATOMS = SELF;)) ) ) 


(@SLOT= COMPONENTS. NOMINAL_FREQUENCY_OUT 

(©SOURCES = (Retrieve ('COMPONT.nxp') ' 

(©TYPE - NXPDB; v 

©FWRD- FALSE; ' 

©UNKNOWN =TRUE; ' 

©PROPS = N AME, COMPONENTJN, COMPONENT OUT, NASAID, \ 

NOMIN AL_FREQUENCY, NOMINAL_FREQUENCY_IN , \ 

NOMINAL_FREQUENCY_OUT, NOMINALGAIN, \ 

NOMINAL POWER IN, NOMIN AL_POWER_OUT; \ 

©FIELDS = "NAME'” 'COMPONENTJN*, "COMPONENT_OUT' , 'NASA_ID",\ 
'NOM FREQ', 'NOM_FREQ_IN', "NOM_FREQ_OUT', V 

'NOM”GAIN', 'NOm”pOWERJN*. "NOM_POWER_OUT*; \ 

©ATOMS -SELF;)) ) ) 


(@SLOT= COMPONENTS. NOMINAL_GAIN 

(®SOURCES= (Retrieve ('COMPONT.nxp') ' 

(©TYPE -NXPDB; ' 

@FWRD = FALSE; ' 

©UNKNOWN =TRUE; ' 

©PROPS = NAME, COMPONENTIN, COMPONENT OUT, NASA ID, \ 

NOMINAL_FREQUENCY, NOMINAL_FREQUENCY_IN, \ 

nominal”frequency_out, nominal jsain, \ 

nominal”power IN, NOMIN AL_POWER_OUT ; \ 

©FIELDS -'NAME', 'COMPONENT JN\ 'COMPONENTOUT', 'NASAJD', \ 
'NOM FREQ', 'NOM_FREQ_IN', *NOM_FREQ_OUT. \ 

•nom”gain*, 'nom”powerjn*, ' nompo wer_out ’ ; ' 

©ATOMS = SELF;)) )” ) 


(@SLOT= COMPONENTS. NOMIN AL_POWER_IN 

(©SOURCES = (Retrieve ('COMPONT.nxp*) ' 

(©TYPE = NXPDB; ' 

©FWRD-FALSE; \ 

©UNKNOWN -TRUE; ' 

©PROPS = NAME, COMPONENTJN, COMPONENT_OUT, NASA ID, \ 

NOMIN AL_FREQUENCY. NOMIN AL_FREQUENCY_IN, \ 

NOMIN AL_FREQUENCY_OUT, NOMINALGAIN, \ 

NOMINAL POWER_IN, NOMIN ALPOWEROUT; \ 

©FIELDS- 'NAME'” 'COMPONENT_IN*, 'COMPONENT OUT', 'NASA ID', \ 
'NOM FREQ', 'NOM_FREQ_IN', "NOM_FREQ_OUT' , \ 

'NOm”gaIN', 'NOMPOWERIN', 'NOMPOWEROUT'; \ 

©ATOMS -SELF;)) )” )” 
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Code Segment 5.4c: Slot Actions to Retrieve & Initialize Properties of COMPONENTS Class 


(@SLOT= COMPONENTS. NOMINAL_POWER_OUT 

(©SOURCES = (Retrieve ('COMPONT.nxp”) ' 

(®TYPE=NXPDB; v 

@FWRD = FALSE; ' 

©UNKNOWN ■= TRUE; ' 

©PROPS = NAME, COMPONENT_IN, COMPONENT_OUT, NASA_ED, \ 

NOMINAL FREQUENCY, NOMINAL_FREQUENCY_IN, \ 

NOMINALFREQUENCY_OUT,NOMINAL_GAIN, \ 

NOMINAL~POWER_IN, NOMINAL_POWER_OUT; \ 

©FIELDS = "NAME*” •COMPONENTJN', ■COMPONENT_OUT', *NASA_ID", \ 
’NOM_FREQ", ■NOM_FREQ_IN’, *NOM_FREQ_OUT’, \ 

”NOM_GAIN', "NOM_POWER_IN’, , NOM_POWER_OUT - ; \ 

©ATOMS = SELF;)) ) ) 


The next two parameters list the property names for which values are to be 
retrieved and a corresponding list of database field names. Notice that whenever any of 
these property values is pursued all of them are retrieved from the database. This was 
done to make the data accesses more efficient. Because the entire record is retrieved on 
the first access, only one database access is required for each components object. The 
final parameter of the retrieve directive lists the atoms for which the retrieve is effected. 
This is a class level definition of sources that are inherited by each components object. 
Defining the atom as self causes only the record that corresponds to the current object 
to be retrieved. 

5.2.2 Initialization of SUBSYSTEMS Parameters 

The properties associated with the subsystems class were introduced in section 

4.2 and defined in Code Segment 4.6. Several of these provide information on the 
structure of the transponder subsystems or nominal values for other parameters. 
Specifically, these properties are name, sensorjn, sensorjout, subsystemjn, and 


SUBSYSTEM OUT. 
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Names of Subsystem Objects 

The slot definitions for initializing the name property of subsystems objects are 
given in Code Segment 5.5. This segment also lists definitions for the dynamic objects 
which represent the channels through the matrix switch. 


Code Segment 5.5: Initialization of < | SUBSYSTEMS \ >.NAME 


(©SLOT- CH1AMP.NAME 

(©INITVAL- ’CHIAMP’) 

(©SOURCES- (RunTimeValue (’CHIAMP')) ) 

) 


(@SLOT = CHIRCVR.NAME 

(©INITVAL = •CH1RCVR") 

(©SOURCES— (RunTimeValue ("CHIRCVR")) ) 

) 


(©SLOT = CH1UPX.NAME 

(©INrrVAL== XH1UPX-) 

(©SOURCES = (RunTimeValue CCHIUPX’)) ) 

) 


(©SLOT- CH2AMP.NAME 

(©INITVAL- ’CH2AMP’) 

(©SOURCES- (RunTimeValue (’CH2AMP’)) ) 

) 


(©SLOT- CH2RCVR.NAME 

(©INITVAL- ’CH2RCVR’) 

(©SOURCES- (RunTimeValue ('CH2RCVR')) ) 

) 


(©SLOT- CH2UPX.NAME 

(©INITVAL- ’CH2UPX’) 

(©SOURCES- (RunTimeValue ('CH2UPX')) ) 

) 


(©SLOT- MSWITCH_CHI 1 .NAME 

(©INITVAL- ’MSVrTrCHjr) 

(©SOURCES- (RunTimeValue (’MSWITCHJ 1 ’)) ) 

) 


(©SLOT- MSWITCH_CH12.NAME 

(©INITVAL- ’MSWITCH_12’) 

(©SOURCES- (RunTime Value CMSWITCHJ2*)) ) 

) 


(©SLOT- MSWITCH_CH21.NAME 

(©INITVAL- ■MSWrrCH_CH21") 

(©SOURCES- (RunTimeValue (’MSWITCH_CH2r)) 

) 

) 

(©SLOT- MSWITCH_CH22.NAME 

(©INITVAL- *MSWrrCH_CH22’) 

(©SOURCES- (RunTimeValue (’MSWTrCH_CH22*)) 

) 

) 
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Linking of Subsystem Input/Output Properties 


The slot definitions for initializing the input/output parameters of subsystems 
objects are given in Code Segment 5.6a through 5.6d. These definitions initialize the 
SENSORJN, sensor out, subsystem JN, and subsystem _out properties of each object that 
represents subsystems of the transponder system. 
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Code Segment 5.6a; Initialization of < \SUBSYSTEMS\ > ,SENSOR_IN / _OUT 


(©SLOT- CH1AMP.SENSORJN 

(©tNITVAL- ’PM_5’) 

(©SOURCES- (RunTimeValue (’PM_5"» ) ) 

(©SLOT- CHlAMP.SENSOR_OUT 

(©INITVAL- "PM_7") 

(©SOURCES- (RunTimeValue ('PM_7')) ) ) 

(©SLOT- CH1RCVR.SENSORJN 

(©INITVAL- "PM_0") 

(©SOURCES- (RunTimeValue (’PM_0’» ) ) 

(©SLOT- CHlRCVR.SENSOR_OUT 

(©INITVAL- ’PM_r) 

(©SOURCES- (RunTimeValue (*PM_1")) ) ) 

(©SLOT- CH1UPX.SENSORJN 

(©INITVAL- 'PM_3') 

(©SOURCES- (RunTimeValue (’PM_3")) ) ) 

(©SLOT- CHlUPX.SENSOR_OUT 

(©INITVAL- ’PM_5") 

(©SOURCES- (RunTimeValue ("PM_5’)) ) ) 

(©SLOT- CH2AMP.SENSOR_IN 

(©INITVAL- ’PM_6") 

(©SOURCES- (RunTimeValue ('PM_6')) ) ) 

(©SLOT- CH2AMP.SENSOR_OUT 

(©INITVAL- 'PM_8') 

(©SOURCES- (RunTimeValue (’PM_8*)) ) ) 

(©SLOT- CH2RCVR.SENSORJN 

(©INITVAL- "PM_0’) 

(©SOURCES- (RunTimeValue (*PM_0*)) ) ) 

(©SLOT- CH2RCVR.SENSOR_OUT 

(©INITVAL- ”PM_2") 

(©SOURCES- (RunTimeValue (*PM_2*)) ) ) 

(©SLOT- CH2UPX.SENSOR_IN 

(©INITVAL- ’PM_4") 

(©SOURCES- (RunTimeValue ('PM_4')) ) ) 

(©SLOT- CH2UPX.SENSOR_OUT 

(©INITVAL- •PM_6*) 

(©SOURCES- (RunTimeValue CPM_6*)) ) ) 
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Code Segment 5.6b: Initialization of < j SUBSYSTEMS | > ,SENSOR_IN / _OUT 


(©SLOT- MSWTTCH_CHll.SENSOR_IN 

(©INITVAL- ’PM_1') 

(©SOURCES = (RunTimeValue (*PM_1’)) 

(©SLOT- MSWrrCH_CHll.SENSOR_OUT 

(©INITVAL- 'PM_3') 

(©SOURCES- (RunTimeValue ("PM_3')) 

(@SLOT= MSWITCH_CH12.SENSOR_IN 

(@INITVAL= -PM_r) 

(@SOURCES= (RunTimeValue (’PM_T)) 

(@SLOT= MSWITCH_CH12.SENSOR_OUT 

(©INITVAL- •PM_4”) 

(©SOURCES- (RunTimeValue ('PM_4’» 

(©SLOT = MS W1TCH_CH2 1 .SENSOR JN 

(©INITVAL- *PM_2‘) 

(©SOURCES = (RunTimeValue ("PM_2")) 

(@SLOT= MSWlTCH_CH21.SENSOR_OUT 

(©INITVAL- -PM_3*) 

(©SOURCES- (RunTimeValue ("PM_3’)) 

(©SLOT- MSWITCH_CH22.SENSOR_IN 

(©INITVAL- T > M_2") 

(©SOURCES- (RunTimeValue CPM_2*)) 

(©SLOT- MSWITCH_CH22.SENSOR_OUT 

(©INITVAL- •PM_4*) 

(©SOURCES- (RunTimeValue (*PM_4’)) 


) ) 


) ) 


) ) 


) ) 


) ) 


) ) 


) ) 


) ) 
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Code Segment 5.6c: 


Initialization of < | SUBSYSTEMS] > .SUBSYSTEM 


(©SLOT* CHI AMP. SUBS YSTEM_IN 

(©INITVAL* 'CH1UPX') ~ 

(©SOURCES = (RunTime Value ('CH1UPX')) ) 

(©SLOT = CHlAMP.SUBSYSTEM_OUT 

(@INITVAL= 'NONE') 

(©SOURCES = (RunTimeValue ('NONE')) ) 

(@SLOT= CH 1 RCVR.SUBS YSTEMJN 

(@tNITVAL= 'NONE') 

(©SOURCES = (RunTimeValue ('NONE')) ) 

(©SLOT = CH1RCVR.SUBSYSTEM_0UT 

(@INITVAL= 'MS WITCH') ” 

(©SOURCES* (RunTimeValue ('MSWITCH')) ) 

(©SLOT* CH1UPX.SUBSYSTEM_IN 

(©INITVAL* 'MS WITCH '7 

(©SOURCES* (RunTimeValue ('MSWITCH')) ) 

(©SLOT* CHlUPX.SUBSYSTEM_OUT 

(©INITVAL* 'CHI AMP') 

(©SOURCES* (RunTimeValue ('CHI AMP’)) ) 

(©SLOT* CH2AMP.SUBSYSTEMJN 

(©INITVAL* 'CH2UPX') ” 

(©SOURCES* (RunTimeValue ('CH2UPX')) ) 

(©SLOT* CH2AMP.SUBSYSTEM_0UT 

(©INITVAL* 'NONE') 

(©SOURCES* (RunTimeValue ('NONE')) ) 

(©SLOT* CH2RCVR.SUBSYSTEM_IN 

(©INITVAL* 'NONE') 

(©SOURCES* (RunTimeValue ('NONE')) ) 

(©SLOT* CH2RCVR.SUBSYSTEM_OUT 

(©INITVAL* 'MSWITCH') 

(©SOURCES* (RunTimeValue ('MSWITCH')) ) 

(©SLOT* CH2UPX. SUBS YSTEMJN 

(©INITVAL* 'MSWITCH')" 

(©SOURCES* (RunTimeValue ('MSWITCH')) ) 

(©SLOT- CH2UPX. SUBSYSTEM J)UT 

(©INITVAL— 'CH2AMP') ” 

(©SOURCES- (RunTimeValue ('CH2AMP')) ) 


IN / OUT 


) 


) 


) 


) 


) 


) 


) 


) 


) 


) 


) 


) 
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Code Segment 5.6d: Initialization of < | SUBSYSTEMS | > ,SUBSYSTEM_IN / _OUT 


(©SLOT- MSWTTCH_CH1 1 .SUBSYSTEMS 

(©INITVAL- "CH1RCVR") 

(©SOURCES = (RunTimeValue (’CH1RCVR - )) ) ) 

(@SLOT= MSWlTCH_CHll.SUBSYSTEM_OUT 

(©INITVAL- -CH1UPX-) 

(©SOURCES- (RunTimeValue ('CH1UPX")) ) ) 

(©SLOT- MSWITCH_CH12.SUBSYSTEM_IN 

(©INITVAL— "CH1RCVR') 

(©SOURCES- (RunTimeValue ("CHIRCVR')) ) ) 

(©SLOT- MS WTTCH_CH 1 2 .SUBS Y STEM_OUT 

(©INITVAL- "CH2UPX") 

(©SOURCES- (RunTimeValue ("CH2UPX")) ) ) 

(©SLOT- MSW1TCH_CH21.SUBSYSTEM_IN 

(©INITVAL- "CH2RCVR") 

(©SOURCES- (RunTimeValue ('CH2RCVR’)) ) ) 

(©SLOT- MSWITCH_CH21 ,SUBSYSTEM_OUT 

(©INITVAL- -CH1UPX’) 

(©SOURCES- (RunTimeValue ('CH2UPX’)) ) ) 

(©SLOT- MSWITCH_CH22.SUBSYSTEM_IN 

(©INITVAL- “CH2RCVR") 

(©SOURCES- (RunTimeValue ("CH2RCVR”)) ) ) 

(©SLOT- MSWITCH_CH22.SUBSYSTEM_OUT 

(©INITVAL- ■CH2UPX”) 

(©SOURCES- (RunTimeValue ("CH2UPX')) ) ) 


5.2.3 Initialization of SENSORS Parameters 


The properties associated with the sensors class were introduced in section 4.3 
and defined in Code Segment 4. 10. Several of these provide information on nominal 
values and for other parameters. Specifically, these properties are description, name, 
NOMINAL, TOLERANCE, type, and zero level. However, before the code segments that 
define these initializations can be discussed, another object must be introduced. 

Recall from Figure 1.2 that there are no signal power level sensors at the input 
to the receiver units at the channel 1 and channel 2 inputs. Also in chapter 3, the 
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concept of a subsystem for isolating faults was defined as a group of components between 
power sensors. Furthermore, the criteria for isolating a fault to find a subsystem who’s 
input signal power level was "GOOD" and output signal power level was ’bad.’ This 
situation resulted in a conflict in defining the channel 1 and 2 receiver subsystems. 

This conflict was resolved by creating a hypothetical signal power level sensor 
for the inputs to the channel 1 and channel 2 receiver subsystems. This sensor would 
always report a ‘GOOD’ reading; as it must be assumed that the uplink signal to the 
transponder is within its parametric range. This hypothetical sensor was represented by 
creating an object called pm_o and initializing its reading and level properties to ’GOOD’ 
and "OK" respectively. Code Segment 5.7 gives these definitions. 


Code Segment 5.7: Definition of Hypothetical Signal Power Level Sensor PMJ) 


(©OBJECT - 


PM 0 



(©PROPERTIES = 

LEVEL 

NAME 

READING ) 

) 



(©SLOT : 

= PM_0.LEVEL 

(©INITVAL- "OK") 

(©SOURCES = (RunTime Value) 

(’OK')) ) 

) 


(©SLOT 

= PM_0.NAME 

(@INITVAL= ■PMJO 

(©SOURCES = (RunTime Value) 

("PM_0")) 

> 

> 

(©SLOT 

= PMJ). READING 

(@CNITVAL= ’GOOD") 

(©SOURCES = (RunTimeValue) 

("GOOD")) 

> 

> 


Names of Sensor Objects 


The slot definitions for initializing the name property of sensors objects are given 


in Code Segments 5.8. 
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Code Segment 5.8: Initialization of < \ SENSORS \ >.NAME 


(©SLOT* BER_1 .NAME 

(©INITVAL* *BER_T) 

(©SOURCES* (RunTime Value ( - BER_1"» ) ) 

(©SLOT* BER2.NAME 

(©INITVAL* ” *BER_2") 

(©SOURCES* (RunTimeValue ("BER_2")) ) ) 

(©SLOT* BER_3.NAME 

(©INITVAL* "BERJ") 

(©SOURCES* (RunTimeValue ("BER^")) ) ) 

(©SLOT* BER4.NAME 

(©INITVAL* ” "BER_4") 

(©SOURCES* (RunTimeValue (*BER_4")) ) ) 

(©SLOT* BER_5.NAME 

(©INITVAL* # BER_5") 

(©SOURCES* (RunTimeValue ("BER_5’ , » ) ) 

(©SLOT* BER_6.NAME 

(©INITVAL* "BER_6") 

(©SOURCES* (RunTimeValue ("BER_6")) ) ) 

(©SLOT* PMJ.NAME 

(©INITVAL* "PM_1") 

(©SOURCES* (RunTimeValue fPMJ")) ) ) 

(©SLOT* PM_2.NAME 

(©INITVAL* ’PM^") 

(©SOURCES* (RunTimeValue CPM_2*)) ) ) 

(©SLOT* PM NAME 

(©INITVAL* *PM_3") 

(©SOURCES* (RunTimeValue ("PM^*)) ) ) 

(©SLOT* PM_4.NAME 

(©INITVAL* "PM_4*> 

(©SOURCES* (RunTimeValue CPM^")) ) ) 

(©SLOT* PM J. NAME 

(©INITVAL* "PM_5 ’) 

(©SOURCES* (RunTimeValue (’PM_5 - )) ) ) 

(©SLOT* PM_6.NAME 

(©INITVAL*” "PM_6") 

(©SOURCES* (RunTimeValue (’ , PM_6*)) ) ) 

(©SLOT* PMJ7.NAME 

(©INITVAL* "PMJ7") 

(©SOURCES* (RunTimeValue ("PMJ7*)) ) ) 

(©SLOT* PM8.NAME 

(©INITVAL* -PM_8 B ) 

(©SOURCES* (RunTimeValue CPM^*)) ) ) 
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Descriptions of Sensor Objects 

The slot definitions for initializing the descriptions of pwrsensors objects are 
given in Code Segment 5.9. These definitions initialize the description property of each 
object that represents a signal power level sensor in the transponder system. 


Code Segment 5*9: Initialization of < [SENSORS] > .DESCRIPTION 


(©SLOT* PM J .DESCRIPTION 

(©INITVAL= "Channel 1 Matrix Switch Input Signal Power Level Sensor") 

(©SOURCES* (RunTime Value ("Channel 1 Matrix Switch Input Signal Power Level Sensor")) )) 

(©S LOT * PM_2 . D ESCRIPTION 

(©INITVAL* "Channel 2 Matrix Switch Input Signal Power Level Sensor") 

(©SOURCES* (RunTimeValue ("Channel 2 Matrix Switch Input Signal Power Level Sensor")) )) 

(©SLOT* PM_3. DESCRIPTION 

(©INITVAL* "Channel I Up-converter Input Signal Power Level Sensor") 

(©SOURCES* (RunTimeValue ("Channel l Up-converter Input Signal Power Level Sensor")) )) 

(©SLOT * PM_4 .DESCRIPTION 

(©INITVAL* "Channel 2 Up-converter Input Signal Power Level Sensor") 

(©SOURCES = (RunTimeValue ("Channel 2 Up-converter Input Signal Power Level Sensor")) )) 

(©SLOT= PM_5 .DESCRIPTION 

(©INITVAL* "Channel 1 HPA Input Signal Power Level Sensor") 

(©SOURCES* (RunTimeValue ("Channel 1 HPA Input Signal Power Level Sensor")) )) 

(©SLOT= PM_6. DESCRIPTION 

(©INITVAL=* "Channel 2 HPA Input Signal Power Level Sensor") 

(©SOURCES = (RunTimeValue ("Channel 2 HPA Input Signal Power Level Sensor")) )) 

(©SLOT * PM_7 .DESCRIPTION 

(©INITVAL* "Channel 1 HPA Output Signal Power Level Sensor") 

(©SOURCES * (RunTimeValue ("Channel 1 HPA Output Signal Power Level Sensor")) )) 

(©SLOT = PM J .DESCRIPTION 

(©INITVAL* "Channel 2 HPA Output Signal Power Level Sensor") 

(©SOURCES* (RunTimeValue ("Channel 2 HPA Output Signal Power Level Sensor")) )) 
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Types of Sensor Objects 


The slot definitions for initializing the type property of sensors objects are given 
in Code Segment 5.10. Each sensor type is initialized at the subclass level for signal 
pwr sensors and data stream berjensors. 


Code Segment 5.10: Initialization of < \BER_ / PWR_SENSOR\ >.TYPE 


(@SLOT= BER_SENSORS.TYPE 

(@INITVAL= "BER") 

(©SOURCES = (RunTimeValue (’BER')) ) ) 

(@SLOT= PWRSENSORS.TYPE 

(@INITVAL= ’PM*) 

(©SOURCES = (RunTimeValue ("PM')) ) ) 


Retrieval of Remaining Property Values from Database 

Only the values of the property name are hard-coded into the frame structure of 
the sensors world. The values for the remainder of the initialized properties are 
retrieved from SENSOR.nxp database. This database is included in section A.l of 
Appendix A. Code Segment 5.11 gives the definitions for OS slot actions that retrieve 
these values. 

Also associated with the slot for sensors.nominal is an IC definition. This 
definition is not related to the initialization of parameters. It is only included here 
because it is attached to the listed slot. This action is required for the ToolBook" 
interface and is discussed in that section of this chapter. 
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Code Segment 5.11: Slot Actions to Retrieve & Initialize Properties of the SENSORS Class 


(©SLOT 8 * SENSORS. NAME 

(©SOURCES* (Retrieve ("SENSOR.nxp") 

(©TYPE= NXPDB; 

©FWRD* FALSE; 

©UNKNOWN 88 TRUE; 

©PROPS = NAME, NOMINAL, TOLERANCE, ZEROLEVEL; 
©FIELDS** "NAME", "NOMINAL", "TOLERANCE", "ZERO_LEVEL"; 
©ATOMS = SELF;)) ) ) 

(©SLOT = SENSORS .NOMINAL 

(©SOURCES 8 * (Retrieve ("SENSOR.nxp") 

(@TYPE= NXPDB; 

©FWRD= FALSE; 

©UNKNOWN = TRUE; 

©PROPS« NAME, NOMINAL, TOLERANCE, ZERO_LEVEL; 
©FIELDS 8 * "NAME", "NOMINAL", "TOLERANCE", "ZEROLEVEL"; 
©ATOMS 8 * SELF;)) ) ) 

(©CACTIONS = (Execute ("RetumNominalData") 

(@ATOMID= SELF; 

©STRING = "©V(©SELF. NOMINAL)";)) ) ) 

(©SLOT = SENSORS TOLERANCE 

(©SOURCES= (Retrieve ("SENSOR.nxp") 

(©TYPE 88 NXPDB; 

©FWRD = FALSE; 

©UNKNOWN 88 TRUE; 

©PROPS** NAME, NOMINAL, TOLERANCE, ZERO_LEVEL; 
©FIELDS 88 "NAME", "NOMINAL", "TOLERANCE", "ZERO_LEVEL"; 
©ATOMS 88 SELF;)) ) ) 

(©SLOT * SENSORS .ZERO_LEVEL 

(©SOURCES* (Retrieve ("SENSOR.nxp") 

(©TYPE 88 NXPDB; 

©FWRD* FALSE; 

©UNKNOWN = TRUE; 

©PROPS* NAME, NOMINAL, TOLERANCE, ZERO_LEVEL; 
©FIELDS 8 * "NAME", "NOMINAL", "TOLERANCE", "ZERO LEVEL"; 
©ATOMS* SELF;)) ) ) 
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5.2.4 Initialization of FAULTJSTATES Parameters 

There are many parameters of the fault jstates hierarchy which have initialized 
values. However, these initializations are very specific to the knowledge of the 
individual diagnostic modules. They are not defined in the FIDEX kernel knowledge 
base. Therefore, they ware discussed when applicable in chapter 8. 



95 


5.3 Definition of Blackboard Objects 


The strength of any frame-based expert system lies in the efficient encoding of 
rule knowledge. Its rules should be generic and operate on conditions that are germane 
rather than specific to certain instances. A common approach that is used to increase the 
efficiency of rule knowledge in frame-based systems is to use a structure called a 
blackboard. 

By using a blackboard, rules can be written to operate on information posted in 
a global structure. The FIDEX system uses this approach. Its rules operate on 
properties associated with four objects. The definitions for these objects are given in 
Code Segment 5.12. 

Code Segment 5.12: Definition of Blackboard Objects 


(©OBJECT = CURRENTCOMPONENT 

(©PROPERTIES = NAME ) ) 

(©OBJECT = CURRENTFAULT 

(©PROPERTIES = NAME ) ) 

(©OBJECT = C URRENT_S EN SOR 

(©PROPERTIES = NAME ) ) 

(©OBJECT = CURRENTSUBSYSTEM 

(©PROPERTIES = 

LEVEL_IN 

LEVEL~OUT 

NAME 

READINGJN 
READINGOUT 
SENSOR JN 

sensor_out ) ) 


5.4 Definition of Objects/Properties for Rule Hypotheses 

This section, and the last section, are leading to a discussion of object/class 
dynamics and slot actions that begins in section 5.5. Several of these dynamics use rule 
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knowledge. NEXPERT” requires that all properties and objects used in a rule, whether 
as conditions or hypotheses, to be defined before the definition of the rule. To facilitate 
the discussion in the following section, all such definitions have been grouped together 
in Code Segment 5.13. The meanings of each object and property are discussed when 
appropriate in section 5.5. 


Code Segment 5.13: Definition of Objects/Properties for Rule Hypotheses 


(©PROPERTY = 
(©PROPERTY = 
(©PROPERTY = 
(©PROPERTY = 
(©PROPERTY = 
(©PROPERTY = 
(©PROPERTY = 
(©PROPERTY = 


BAD ©TYPE* Boolean;) 

Bad Sensors ©TYPE* Boolean;) 

GOOD ©TYPE* Boolean;) 

HIGH ©TYPE* Boolean;) 

LOW ©TYPE* Boolean;) 

Nominal_Sensor_DaU ©TYPE* Boolean;) 

OK ©TYPE = Boolean;) 

ZERO ©TYPE = Boolean;) 


(©OBJECT* Evaluate_Certainty_Factor* 

(©PROPERTIES * Value ©TYPE* Boolean; ) 

(©OBJECT = Model_Malrix_Switch_SubSystem 

(©PROPERTIES = Value ©TYPE* Boolean; ) 

(©OBJECT* Retum_BAD_Sensors 

(©PROPERTIES* Value ©TYPE* Boolean; ) 

(©OBJECT* Retum_Nominal_Sensor_Data 

(©PROPERTIES* Value ©TYPE* Boolean; ) 

(©OBJECT* Sc nsor_Leve ^Description 

(©PROPERTIES* 

HIGH 

LOW 

OK 

ZERO ) ) 

(©OBJECT* Sensor_Reading_Description 

(©PROPERTIES* 

BAD 

GOOD ) ) 


(©OBJECT* TBK_Requert 

(©PROPERTIES* 

Bad_Sensors 
Nominal Sensor Data 
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5.5 Object/Class Dynamics and Slot Actions 

The values of many properties introduced in chapter 4 represent dynamic 
quantities. Such properties are those used to simulate the propagation of a signal through 
the transponder system, evaluate qualitative descriptions of parameter values, and drive 
the inference strategies of the expert system. 

5.5.1 Dynamics and Slot Actions of the COMPONENTS Class 

The properties associated with the components class were introduced in section 

4.1 and defined in Code Segment 4.1. Several of these simulate the propagation of the 
communication signal through the transponder system. Specifically, these properties are 
gain, power _in, power out, and their model_ counterparts. 

Propagation of Signal Power Levels Through Components 

The slot definitions which simulate the propagation of signal power levels through 
the components of the transponder system are given in Code Segment 5.14. The three 
slots used in this simulation are < | components \ > . gain, power JN, and power_out. 
These are class level slot definitions which are inherited by all component objects in the 
components hierarchy. 

The propagation of signal power levels is simulated using two different techniques 
for driving slot actions. The first and most useful approach is called data-driven. In this 
approach the changing of data at the input to a component is used to drive the evaluation 
of other component object property values. 
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Code Segment 5.14: Propagation of Signal Power Levels Through Components 


(@SLOT= COMPONENTS. GAIN 

(©SOURCES — (Do (SELF. POWER OUT-SELF.POWERJN) (SELF. GAIN)) ) 

(@C ACTIONS’- (Do (SELF.POWER JN + SELF.GAIN) (SELF.POWER_OUT)) )) 

(©SLOT- COMPONENTS. POWERIN 

(©SOURCES = (Do (\SELF.COMPONENT_IN\.POWER_OUT) (SELF.POWER_IN))) 

(©CACTIONS — (Do (SELF.POWER_lN + SELF.GAIN) (SELF.POWER_OUT)) )) 

(@SLOT= COMPONENTS. POWEROUT 

(©SOURCES = (Do (SELF.POWER_IN + SELF.GAIN) (SELF.POWER_OUT)) ) 

(©CACTIONS = (Do (SELF.POWER_OUT) (\SELF.COMPONENT_OUTVPOWER_IN)))) 


Recall from section 4.1 that the signal power level at the input to a component 
is represented by the property powerjn. Whenever the value of this property changes, 
IC actions, mCACTiONS =...), are taken. The new value of powerjn is added with the 
current value of the component’s gain property to calculate a new value for the signal 
power level at the output to a component. This new value is placed in the property that 
represents this quantity, powerout. 

Changing this output power level again stimulates another IC action to be taken. 
Whenever the value of a component’s power_out property changes, it posts this new 
value as the signal power level at the input to the next component in the transponder’s 
signal path. (The negligible attenuation of component couplings are disregarded.) To 
do this, it must evaluate the string value of its component out property; which was 
initialized to the object name of the component object at its output in section 5.2.1. 

Posting this new signal power level as the input power level of the next 
component stimulates the same sequence of IC actions in the properties of that component 
object. In this manner, the signal power levels through out the transponder system are 
simulated in the objects which represent the transponder components. 

The propagation of signal power levels is also simulated using another technique 
for driving slot actions. This approach is called source-driven. It is useful when values 
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of parameters are not known and must be calculated. In this approach the pursuit of a 
value for one parameter is used to drive the evaluation of other property values. 

Whenever values for a component object’s GAIN or power_out are required but 
unknown, OS actions, (qsovrces =...), provide the means for calculating them from other 
properties. Should the value of a component object’s powerjn be required but 
unknown, OS actions provide the means for it to look to the output signal power level 
of its input component, componentjn. Again, when these values are obtained, changed 
from unknown, their IC actions propagate the new values. 

Propagation of Modeled Signal Power Levels Through Components 

Also recall from section 4.1 that a primitive model-based reasoning overhead is 
included in the object dynamics of the FIDEX system. These dynamics are effected 
through the model_ prefixed properties listed in Code Segment 4. 1 . The propagation of 
these modeled signal power levels through components is implemented in the same 
manner as those discussed with Code Segment 5.14. The definitions for these slot 
actions are given in Code Segment 5.15. 
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Code Segment 5.15: Propagation of Modeled Signal Power Levels Through Components 


(©SLOT- COMPONENTS. MODEL GAIN 

(©SOURCES'* (Do (SELF.MODEL_POWER_OUT-SELF.MODEL_POWER_IN) \ 

(SELF.MODEL GAIN)) ) 

(©CACTIONS = (Do (SELF.MODEL_POWER_IN +SELF.MODEL_G AIN) \ 

(SELF.MODEL_POWER_OUT)) ) ) 

(©SLOT- COMPONENTS. MODEL_POWER_IN 

(©SOURCES- (Do (\SELF.COMPONENT_lN\.MODEL_POWER_OUT) ' 

(SELF.MODELPOWERJN)) ) 

(@C ACTIONS — (Do (SELF.MODEL~POWER_IN+SELF.MODEL_GAIN) \ 

(SELF.MODEL_POWER_OUT)) ) ) 

(©SLOT- COMPONENTS .MODEL_POWER_OUT 

(©SOURCES- (Do (SELF.MODEL_POWER_IN+SELF.MODEL_GAIN) ' 

(SELF.MODEL_POWER_OUT)) ) 

(©CACTIONS- (Do (SELF.MODEL_POWER_OUT) ' 

(\SELF.COMPONENT_OUT\.MODEL_POWER_IN)) ) ) 


Propagation of Signal Power Levels Through MultiPort Components 

As discussed in section 4.1, there are a number of multiple port components 
within the transponder. The parameters which represent signal quantities at these 
additional ports were represented in those component objects by the properties suffixed 
by 2 in Code Segment 4.3. However, the existence of multiple ports does not 
complicate the simulated propagation the transponder signal. The techniques are simply 
expanded as shown in Code Segment 5.16. 

This segment does not give a complete listing. The scope of such a listing would 
be of great length and very redundant. Code Segment 5.16 simply provides two 
examples of how the gain of the second channel through the matrix switch is simulated. 
For a complete listing, refer to Appendix A. 
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Code Segment 5.16: Propagation of Signal Power Levels Through Multiple Port Components 


> > * INCOMPLETE ♦ < < 


(@SLOT= SWITCHES. GAIN2 

(©SOURCES = (Do (SELF. PO WER_OUT_2-S ELF . PO WER_IN_2) (SELF.GAIN_2)) 

(©CACTIONS = (Do (SELF . PO WER_IN_2 + SELF .G AIN_2) (SELF.POWER_OUT_2)) 


) 

)) 


(©SLOT* 


SWITCHES. MODEL GAIN_2 


(©SOURCES = 


(Do 


(SELF.MODEL POWER OUT_2-SELF.MODEL_POWER_IN_2)\ 


(SELF.MODEL_GAIN_2)) ) 

(©CACTIONS = (Do (S ELF .MODEL_PO WER_IN_2 + SELF ,MODEL_G AIN_2) \ 

(SELF.MODEL_POWER_OUT_2)) ) ) 


5.5.2 Dynamics and Slot Actions of the SUBSYSTEMS Class 

The properties associated with the subsystems class were introduced in section 

4.2 and defined in Code Segment 4.6. Several of these are used to represent qualitative 
descriptions of signal power sensor readings and levels throughout the transponder 
system. Another property is responsible for loading and initializing the 
diagnostic module associated with the specific subsystems. And finally, recall that the 
various channels through matrix switch subsystem were modeled as a series of dynamic 
objects. This subsection discusses these dynamics of the subsystems class. 

Dynamic Modeling of the Matrix Switch Subsystem 

Table 1.2 listed four permutations of signal paths through the matrix switch. 
Correspondingly, there are four signal paths through the matrix switch subsystem. Each 
of these paths was represented by an object defined in Code Segments 4.9a and 4.9b. 
However at any given time, only two of these paths are propagating a signal through the 
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transponder. Which two of those four is determined by the configuration of the matrix 
switch component. 

To represent this configuration a string property called config was attached to 
the object that represents the matrix switch component, mswitch. This property is set 
to a character that represents a particular configuration of the switch. Code Segment 
5.17 gives the definition for a slot which is used to obtain a value for this property. 


Code Segment 5.17: Sources for Matrix Switch Configuration 


(@SLOT= MSWITCH .CONFIG 

(©SOURCES = (Execute ("RequestMatrixSwitchConfig*)) ) ) 


The OS action of this slot execute an external handler that is associated with the 
ToolBook" Graphical User Interface (GUI). This handler ascertains a value for the 
switch configuration and place it in the CONFIG property of the matrix switch. 

In the current phase of development of the transponder system, only two 
configurations of the matrix switch are possible. These are represented by either "A" or 
■B. * When the ToolBook" handler sets the configuration property value, a hypothesis 
called Model JA at rix_S\vitch -Subsystem is placed on the agenda through a process called 
gating. 

This hypothesis is supported by the two rules defined in Code Segment 5.18. 
Based on the value of the mswitch.config property, only one of these rules may fire. 
Each rule provides actions, (@rhs=...), that dynamically attaches two objects to the 
subsystems class. The single rule that fires attaches objects which represent active signal 
paths through the matrix switch as subsystems of the transponder. As such, these objects 
inherit all property values and slot actions associated with that class. 
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Code Segment 5.18: Rules That Model the Matrix Switch Signal Paths as SUBSYSTEMS 


(@RULE= RULE 012_MODEL_MATRDC_SWirCH 

(@LHS= 0 * ~ (MSWITCh'cONFIG) CB')) ) 

(@HYPO= Model Matrix Switch_SubSystem) 

(@RHS= (CreateObject ” (MSWTTCH_CH12) (| SUBSYSTEMS!)) 

(CreateObject (MSWITCHCH2I) (| SUBSYSTEMS!)) )) 

(@RULE= RULE_01 1 MODEL_MATRK_SWITCH 

(@LHS= fla (MSWTTCH~CONFlG) ('A')) ) 

(@HYPO= ModeI_Matrix Switch_SubSyrtem) 

(@RHS= (CreateObject (MSWITCH_CH11) (| SUBSYSTEMS!)) 

(CreateObject (MSWITCH CH22) ([SUBSYSTEMS!)) )) 


Qualitative Descriptions of Input/Output Sensor Quantities 

The knowledge for isolating faults to the subsystems of the transponder is 
contained in another knowledge base, called ISOLATE.tkb. Furthermore, the knowledge 
bases required to diagnose faults within isolated subsystems are contained in still other 
files. Ea ch of these modules uses information provided by several properties of the 
subsystems class. Therefore, the kernel knowledge base must provide a means for 
ascertaining all required information. 

Isolation requires values for the reading reported by the sensors at the input and 
output of each subsystem. As discussed in section 4.2, these strings are to be placed in 
the reading in and readingjout properties of a subsystem. Diagnostics requires values 
for the level reported by the sensors at the input and output of each subsystem. As also 
discussed in section 4.2, these strings are to be placed in the leveljn and level_out 
properties of a subsystem. The slot actions listed in Code Segment 5.19 are defined at 
the subsystems class level and are used to obtain values for these properties from the 
sensors hierarchy. 
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Code Segment 5.19: Qualitative Descriptions for SUBSYSTEMS Input/Output Quantities 


(©SLOT- SUBSYSTEMS. LEVEL IN 

(©SOURCES = (Do (\SELF.SENSOR_IN\. LEVEL) (SELF.LEVEL_IN)) ) ) 

(©SLOT- SUBSYSTEMS. LEVEL_OUT 

(©SOURCES- (Do (\SELF.SENSOR_OUT\. LEVEL) (SELF .LEVEL_OUT)) )) 

(©SLOT- SUBSYSTEMS ,READING_IN 

(©SOURCES- (Do (\SELF.SENSOR_IN\.READING) (SELF ,READING_IN)) )) 

(©SLOT- SUBSYSTEMS. READING_OUT 

(©SOURCES- (Do (\SELF.SENSOR_OUT\.READING) (SELF .READING_OUT)) )) 


Recall from section 5.2.2 that names of the objects that represent the sensors at 
a subsystems input and output are initialized within the properties sensorjn and 
sensor out. Ea ch slot action shown in Code Segment 5.19 provides the OS actions to 
evaluate these sensor names and acquire the qualitative descriptions as required. 

Dynamics of an Isolated Subsystem Object 

The job of the isolation module is to set the isolated property of the objects that 
represents the subsystem that has been isolated. The knowledge required for this is 
discussed later in chapter 7. For now, the dynamics which occur when this property is 
set will be discussed. 

Code Segment 5.20 defines a class level slot for the isolated property of 
subsystems. During initialization, and at run time, the value of this property is set to 
false for all objects in the subsystems class. The run time value directive in the OS 
actions assures that this is the case for the dynamically attached object that were 
discussed earlier. 
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Code Segment 5 . 20 : Dynamics of < | SUBSYSTEMS | >. ISOLATED 


(©SLOT** SUBSYSTEMS. ISOLATED 

(©INITVAL** FALSE) 

(©SOURCES** (RunTimeValue (FALSE) ) ) 

(©C ACTIONS** (Execute ("Retumlsolation") ' 

(©ATOMID=SELF;©STRING — "©V(©SELF.NAME)";)) ) ) 


When the isolation module sets the isolated property of a subsystem object to 
true, a IC action is initiated. This action executes an external handler that is defined 
within the ToolBook” GUI. Two parameters are passed to this handler. The first is the 
name of the object atom, (@atomid=...), for the isolated subsystem. The key word self 
is used to pass the name of the subsystem object which triggered this IC action. Also 
passed is the value of the subsystem’s name property. Both of these parameters are used 
within the ToolBook” GUI. 

When the GUI has finished informing the user of the results from the isolation 
phase, the handler for Retumholation sets the diagnostic module property of the 
subsystem object that called it. This is why the atom ID was passed as a parameter. 
Code Segment 5.21 lists the definitions for slots associated with this property for each 
object in the subsystems class. It is the IC actions associated with these slots which 
effect the chaining to the specialized diagnostic modules for the specific subsystems of 


the transponder. 


Code Segment 5.21: Chaining to Diagnostic Modules 


(@SLOT= CHI AMP.DIAGNOSTIC_MODULE 

(@initval= false) 

(©SOURCES = (RunTimeValue (FALSE)) ) 

(©CACTIONS* (LoadKB ('CHI AMP.lkb’) (©LEVEL = ENABLE;)) 

(©SLOT* CH 1 RCVR . DIAGNOSTIC_MODULE 

(@INITVAL= FALSE) 

(©SOURCES = (RunTimeValue (FALSE)) ) 

(@C ACTIONS = (LoadKB ('CH)RCVR.tkb') (@LEVEL= ENABLE;)) 

(©SLOT* CH 1 UPX .DIAGNOSTIC_MODULE 

(@INITVAL= FALSE) 

(©SOURCES = (RunTimeValue (FALSE)) ) 

(©CACTIONS* (LoadKB ('CHlUPX.tkb') (©LEVEL* ENABLE;)) 

(@SLOT= CH2AMP.DlAGNOSTlC_MODULE 

(@INITVAL= FALSE) 

(©SOURCES = (RunTimeValue (FALSE))) 

(@CACTIONS= (LoadKB ('CH2AMP.tkb') (©LEVEL* ENABLE;)) 

(@SLOT= CH2RCVR.DlAGNOSTIC_MODULE 

(@tNITVAL= FALSE) 

(©SOURCES = (RunTimeValue (FALSE)) ) 

(@CACTIONS= (LoadKB ('CH2RCVR.tkb') (©LEVEL = ENABLE;)) 

(@SLOT= CH2UPX.DIAGNOSTIC_MODULE 

(@INITVAL= FALSE) 

(©SOURCES = (RunTimeValue (FALSE)) ) 

(©CACTIONS* (LoadKB ('CH2UPX.tkb') (©LEVEL “ENABLE;)) 

(@SLOT= MSWITCH_CH 1 1 .DIAGNOSTIC_MODULE 

(@INITVAL= FALSE) 

(@SOURCES= (RunTimeValue (FALSE)) ) 

(@CACTIONS= (LoadKB ('MSWITCH.tkb’) (®LEVEL= ENABLE;)) 

(@SLOT= MSWITCH_CH12.DlAGNOSTIC_MODULE 

(©INITVAL* FALSE) 

(©SOURCES = (RunTimeValue (FALSE)) ) 

(©CACTIONS = (LoadKB ('MSWITCH.tkb') (©LEVEL “ENABLE;)) 

(@SLOT= MSWITCH_CH21 ,DIAGNOSTIC_MODULE 

(@INITVAL= FALSE) 

(©SOURCES* (RunTimeValue (FALSE)) ) 

(@CACTIONS= (LoadKB ('MSWITCH.tkb') (©LEVEL* ENABLE;)) 

(@SLOT= MSWTTCH_CH22.DIAGN0ST1C_M0DULE 

(®INITVAL“ FALSE) 

(©SOURCES* (RunTimeValue (FALSE)) ) 

(©CACTIONS* (LoadKB ('MSWITCH.tkb’) (©LEVEL* ENABLE;)) 
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As for the isolated property, the value of each object’s diagnostic module 
property is set to false both during initialization and at run time. When the GUI handler 
sets this value to true an IC action is stimulated. This action loads the specialized 
diagnostic knowledge base associated with the isolated subsystem object. As there is one 
diagnostic knowledge base for each subsystem, a slot must be defined at the object level 
for each subsystem object. 

5.5.3 Dynamics and Slot Actions of the SENSORS Class 

The properties associated with the sensors class were introduced in section 4.3 
and defined in Code Segment 4.10. Several of these are used to ascertain qualitative 
descriptions of the data reported by the sensors of the transponder system. Specifically, 
these properties are data, error, level, and reading. 

Slot Actions for Qualitative Descriptions of Sensor Quantities 

The slot definitions which ascertain qualitative descriptions of the data reported 
by sensor components are given in Code Segment 5.22. The values for sensor data are 
provided through the GUI. As these values change, IC actions defined at the class level 
drive the evaluation of qualitative discriptions for the sensor’s reading and level. The 
first three actions associated with data reset the values of a sensors ERROR, reading, and 
level to unknown values. This is done to force their re-evaluation when the next three 
actions are taken. Assigning the value of a slot to itself, as done in the last three IC 
actions associated with data, is an efficient method for forcing the evaluation of a slot. 
Neuron Data, Inc., the publishers of NEXPERT", recommends this technique for 


situations such as this one. 
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(©SLOT= 

(©SLOT; 

(©SLOT 


(©SLOT 


Code Segment 5.22: Slot Actions for Qualitative Descriptions of Sensor Quantities 


SENSORS. DAT A 


(©C ACTIONS- 


(Reset 

(Reset 

(Reset 

(Do 

(Do 

(Do 


(SELF. ERROR)) 
(SELF. READING)) 
(SELF. LEV EL)) 
(SELF. ERROR) 
(SELF. READING) 
(SELF. LEV EL) 


(SELF.ERROR)) 
(SELF. READING)) 
(SELF. LEVEL)) ) 


= SENSORS. ERROR . 

(©SOURCES = (Do 


(SELF. DAT A-SELF. NOMINAL) 


(SELF.ERROR)) ) 


= SENSORS .READING 

(©SOURCES= (Do (SELF. NAME) (CURRENT_SENSOR.NAME)) 
(Reset (Sensor_Reading_Description.BAD)) 

(Do (Sensor_Reading_Description.BAD) 

(Se nsor_Read i ngJDe sc riplion.B AD)) 

(Reset (Sensor_Reading_Description.GOOD)) 

(Do (Sensor_Reading_Desc ription. GOOD) 

($ensor_Reading_Dcscription.GOOD)) ) 

(©C ACTIONS = (Execute ("RetumSensorReading") 

(©ATOMID=SELF;@STRING = *©V(©SELF.READING)";)) ) 


SENSORS. LEVEL 


(©SOURCES- 


(Do 

(Reset 

(Do 

(Reset 

(Do 

(Reset 

(Do 

(Reset 

(Do 


(@C ACTIONS- (Execute 


(SELF.NAME) (CURRENT_SENSOR.NAME)) 
(Sensor_Level_Description.ZERO)) 

(S e nsorLe veI_Dcsc ription .ZERO) 
(SensorJLevel_Description.ZERO)) 
(Sensor_Level_De$cription.LOW)) 
(Sensor_Level_Description.LOW) 

(Se nsor_Level_Desc ription .LOW)) 

(Se nsor_Le vel_De sc ription . HIG H)) 

(Se nsor_Level_De sc ription . HIG H) 
(SensorJLeveI_Description.HIGH)) 

(Sensor_Level_De sc ription. OK)) 
(Sensor_Level_Description.OK) 
(Sensor_Level_Description.OK)) ) 

("RetumSensorLevel ") 


(@ ATOMID = SELF;©STRING = *'©V(@SELF. LEVEL)";)) ) 


) 


\ 

\ 

\ 


\ 

\ 

\ 

\ 

\ 


The value of the current sensors’s error, SELF.ERROR . is unknown at this time. 
When its value is evaluated, the OS actions associated with the class level slot definition 
calculate the difference between the current and nominal sensor data values as the signed 
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error in the sensor reading. This value is used in determining values for the reading and 
level. It is discussed shortly. 

The sources for reading and level perform very similar functions. When values 
for each of these are pursued, the OS actions do the following. First, the value for name 
of the blackboard object current jensor is set to the name of the current sensor object. 
Then a sequence of slots are reset and then forced to be evaluated. These slots represent 
the hypotheses of rules which ascribe the qualitative descriptions to the sensor quantities 
in question. This list is pursued sequentially until a value is set. Once a value is set, 
the OS actions are terminated and the remainder of the directive ignored. The rules 
which ascribe qualitative descriptions to sensor readings and levels are defined in Code 
Segments 5.23 and 5.24. 

Also defined with the slots for sensors.reading and .level are IC actions which 
fire when the sources establish their values. These actions communicate the new 
qualitative descriptions to an external handler that is defined in the ToolBook GUI. 



Code Segment 5.23: Rules to Ascribe Qualitative Descriptions to Sensor Levels 
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(@RULE= RULE_003_QUAUFICATION_OF_HIGH_SENSOR_LEVELS 

(@LHS= (> (\CURRENT_SENSOR. NAM E\. ERROR) (0)) ) 

(@HYPO= Sensor Level_Descriplion.HIGH) 

(@RHS= (Lei (\CURRENT_SENSOR. NAM EV LEVEL) ("HIGH")) ) ) 

(@RULE= RULE (K)4_QUALIF1CAT10N_0F_L0W_SENS0R_LEVELS 

(@LHS= (< " (\C URRENT_S ENSOR.NAMEV ERROR) (0)) ) 

(@HYPO = Sensor_Level_Description.LOW) 

(@RHS= (Lei (\CURRENT~SENSOR.NAME\. LEVEL) (’LOW’)) ) ) 

(@RULE= RULE_005_QUAUFICATlON_OF_OK_SENSOR_LEVELS 

(@LHS= (< = (ABS(\CURRENT_SENSOR.NAME\.ERROR)- ' 

\CURRENT_SENSOR.NAME\.TOLERANCE) (0)) ) 

(@HYPO= Sensor_Level_Description.OK) 

(@RHS= (Let (\CURRENT~SENSOR.NAME\.LEVEL) (’OK')) ) ) 

(@RULE= RULE_(X)6_QUALIFICATION_OF_ZERO_SENSOR_LEVELS 

(@LHS= (< = ” (\CURRENT_SENSOR. NAMEt.DAT A- \ 

\CURRENT_SENSOR.NAME\.ZERO_LEVEL) (0)) ) 

(@HYPO= Sensor_Level_Description.ZERO) 

(@RHS= (Ut (\CURRENT3ENSOR.NAME\.LEVEL) (’ZERO’)) ) ) 


Code Segment 5.24: Rules to Ascribe Qualitative Descriptions to Sensor Readings 


(@RULE= RULE_001_QUALIF1CAT10N_OF_BAD_SENSOR_READINGS 

(@LHS= (> ” (ABS(\CURRENT_SENSOR.NAME\.ERROR)- ' 

\CURRENT_S EN SOR . N AM E\ .TOLERANCE) (0)) ) 

(@HYPO= Sensor Re»ding_Description.BAD) 

(@RHS= (Let (\CURRENT SENSOR. NAME\.READING) (’BAD’)) 

(CreateObject” (\CURRENT_SENSOR.NAME\) (|BAD_SENSORS|)) 

(Lei (\CURRENT_SENSOR. NAM E\. EVALUATED) (TRUE)) )) 

(@RULE= RULE_002_QUALIFlCATlON_OF_GOOD_SENSOR_READINGS 

(@LHS= (< = (ABS(\CURRENT_SENSOR.NAME\.ERROR)- 

\CURRENT_SENSOR. NAM E\. TOLERANCE) (0)) ) 

(@HYPO= Sensor Reading Descnplion.GOOD) 

(@RHS= (Let (\CURRENT SENSOR. NAMEN.READING) (’GOOD’)) 

(Lei (\CURRENT_SENSOR.NAME\.EVALUATED) (TRUE)) )) 


5.5.4 Implementation of MYCIN Technique and Certainty Analysis 

The MYCIN technique for the incremental accumulation of evidence and its use 
in certainty analysis was first introduced in sections 3.3.2 and 3.3.3. Then, the 
representation of properties for certainty analysis were given in Code Segment 4.14. 
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This section discusses the implementation of the MYCIN technique at the 
CERTAINTY ANALYSIS class level. 

The slot definitions for the properties involved in certainty analysis are given in 
Code Segment 5.25. Supporting rules for ascribing qualitative descriptions to 
confidence in fault state hypothesis are listed in Code Segment 5.26. 
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Code Segment 5.25: certainty analysis 


(@SLOT = CERTAINTYANALYSIS.AB 
(©INITVAL^ 0.0) 

(©SOURCES = (RunTime Value (0.0)) ) 

(©CACTIONS = (Do ((SELF .AB-SELF.AD)/MIN (SELF .AB,SELF. AD)) \ 

(SELF.CF)) ) ) 

(©SLOT « CERTAINTY_ANALYSIS.AD 
(©INTTVAL™ 0.0) 

(©SOURCES = (RunTime Value (0.0)) ) 

(©CACTIONS = (Do ((SELF AB-SELF.AD)/MIN(SELF.AB, SELF .AD)) \ 

(SELF.CF)) ) ) 

(©SLOT= CERT A INTYAN A LYSIS . CF 
(©INTTVAL= 0.0) 

(©SOURCES = (RunTimeValuc (0.0)) ) 

(©CACTIONS = (Do * (SELF. NAME) (CURRENT^ FAULT .NAME)) 

(Reset (Evaluate_Certainty_Factors)) 

(Do (Evaluate_Ccrtamty_Faclors) \ 

(Evaluate_Certainty_FacU>rs)) ) ) 

(©SLOT = CERTAINTY_ANALYSIS.MB 
(©ENTTVAL= 0.0) 

(©SOURCES= (RunTimeValuc (0.0)) ) 

(©CACTIONS = (Do (SELF. AB + SELF. MB *(1-S ELF. AB)) (SELF.AB)) 

(Reset (SELF. MB)) ) ) 

(©SLOT= CERT A INTY_ANA LYSIS . MD 
(©INITVAL= 0.0) 

(©SOURCES = (RunTimeValuc (0.0)) ) 

(©CACTIONS = (Do (SELF.AD + SELF. MD*(1 -SELF .AD)) (SELF .AD)) 

(Reset (SELF.MD)) ) ) 
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Code Segment 5.26: Rules to Ascribe Qualitative Descriptions to Fault State 

Confidence Factors 


(©RULE 55 RULE 029_QUALIFICATION_OF_CONFIDENCE_REJECTED 

<©LHS= (<=~ (NCURRENT_FAULT.NAME\.CF) (-0.9)) ) 

(©HYPO 55 Evaluatc_CerUmty_Factora) 

(©RHS* (Let CCUR RENT_F A ULT . N A ME\ .CONFIDENCE) (’REJECTED")) 

(Let (\CURRENT_FA ULT. NAMEN. VERIFIED) (FALSE)) ) ) 

(©RULE * RULE 028 QUALIFlCATION_OF_CONFIDENCE VERYIMPROBABLE 

(©LHS * (<*” OCURRENT_FAULT.NAME\.CF) (-0.75)) 

(> (\CURRENT_FAULT.NAME\.CF) (-0.9)) ) 

(©HYPO* EvaluatcCertaintyFactors) 

(©RHS= (Let (\CURRENT_FAULT.NAME\. CONFIDENCE) \ 

("VERY^IMPROBABLE")) ) ) 

(©RULE 5=1 RULE 027_QUALIFICATION_OF_CONFIDENCE_IMPROBABLE 

(©LHS* (< = " (\CURRENT_FAULT.NAMEN.CF) (-0.5)) 

(> (\CURRENT_FAULT.NAME\.CF) (-0.75)) ) 

(@HYPO= Evaluate Certain ty_Factors) 

(©RHS* (Let (\CURRENT_FAULT.NAME\. CONFIDENCE) ("IMPROBABLE")) )) 

(©RULE* RULE_026__QUALIFICATlON_OF_CONFIDENCE UNLIKELY 

(©LHS = (<= (\CURRENT_FAULT.NAME\.CF) (-0.25)) 

(> (\CURRENT_FAULT .NAME\.CF) (-0.5)) ) 

(©HYPO* Eva!uate_Certainty_Factors) 

(©RHS* (Let (\CURRENT - FAULT.NAME\.CONFIDENCE) ("UNLIKELY")) )) 

(©RULE* RULE 025__QUALIF1CATION_OF_CONFIDENCE UNKNOWN 

(©LHS= (> ~ 0 CURRENT F A ULT . N A MEN . CF) (-0.25)) 

(< (\CURRENT_FAULT.NAME\.CF) (0.25)) ) 

(©HYPO= Evaluate Certainty Factors) 

(©RHS* (Let (\CURRENT_FAULT. NAMEN. CONFIDENCE) ("UNKNOWN")) )) 

(©RULE* RULE 024 QUALIFICAT10N_OF_CONFIDENCE POSSIBLE 

(©LHS* <>* CCURRENT_FAULT.NAME\.CF) (0.25)) 

(< (\CURRENT_FAULT.NAME\.CF) (0.5)) ) 

(©HYPO* Evaluate Certainty ^Factors) 

(©RHS* (Let (\CURRENT_FAULT. NAMEN. CONFIDENCE) ("POSSIBLE")) )) 

(©RULE * RULE 023 QUALIFlCATION_OF_CONFIDENCE LIKELY 

(©LHS* (>* (\CURRENT FA ULT. NAMEN. CF) (0.5)) 

(< (\CURRENT_FAULT.NAME\.CF) (0.75)) ) 

(©HYPO* Evaluate Certain ty_Fac tors) 

(©RHS* (Let (\CURRENT_FAULT.NAME\. CONFIDENCE) (* LIKELY*)) )) 

(©RULE = RULE_022 QUALIFICATION_OF_CONFIDENCE PROBABLE 

(©LHS* (> = " (\CURRENT_FA ULT . N AMEN .CF) (0.75)) 

(< (\CURRENT_FAULT.NAMEN.CF) (0.9)) ) 

(©HYPO* Evaluatc_Ccrtainty Factors) 

(©RHS* (Let (\CURRENT_FA ULT. NAME\. CONFIDENCE) ("PROBABLE")) )) 

(©RULE* RULE_021 QUALIF1CATION_OF_CONFTDENCE_ESTABLlSHED 

(©LHS* (> * “ (\CURRENT_FA ULT. N AMEN. CF) (0.9)) ) 

(© HYPO = Evaluate_Ccrlainty_Factors) 

(©RHS* (Let (\ CURRENT FA ULT .NAMEN. CONFIDENCE) ("ESTABLISHED")) 

(Let (\CURRENT_F A ULT. NAMEN. VERIFIED) (TRUE)) ) ) 
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5.5.5 Dynamics of Interaction with ToolBook” Interface 

There are three properties of the sensors class that are used to communicate 
information to the ToolBook” GUI. These properties are rtn level, rtn_nominal, and 
rtn_reading. They were introduced in section 4.3 and defined in Code Segment 4. 10, 
but their descussion was delayed to now. 

Their operation is simple. Whenever the GUI needs the current value of a 
sensors level, nominal, or reading property, it can toggle the values of these slots 
between true and false. The IC actions given in Code Segment 5.27 are then 
stimulated to execute externally defined handlers and return the desired quantity. 


Code Segment 5.27: Definition of GUI Interactive Slots 


(@SLOT= SENSORS.RTN_LEVEL 

(@C ACTION S = (Execute ("RetumSensorLever) t 

(@ATOMID = SELF;@STRING="®V(@SELF.LEVEL)’;)) ) ) 

(@SLOT= SEN SORS ,RTN_N OM IN AL 

(@C ACTIONS = (Execute ("RetumNo mi rial Data") \ 

(@ ATOMID = SELF; ©STRING = '@V(@SELF. NOMINAL)';)) )) 

(@SLOT= SENSORS. RTN_READING 

(@C ACTIONS = (Execute ("RetumSensorReading") ' 

(@ATOMID=SELF;@STRING='@V(@SELF.READING)*;)) ) ) 


A similar slot was defined earlier in Code Segment 5.11 for the IC actions of 
sensors. nominal. It is a redundancy of the sensors.rw nominal slot in that it 
communicates the value of the current sensor objects nominal data to the GUI. 
However, this redundancy added efficiency in speed and was included with the slot 
definition for the nominal property slot. 

The final code segment discussed in this chapter defines two rules which are 
required for the GUI. RULE_90i is used to retrieve and return nominal sensor data to the 
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GUI. RULE 902 is used to a list of all sensors who’s readings were described as "bad. * 
Each of these use the IC actions defined in Code Segment 5.27 by toggling sensor 
property values. 


Code Segment 5.28: Rules Required by ToolBook Interface 


(©RULE = RULE 902 RETURN_LIST_OF_BAD_SENSORS_TO_ToolBook 

(©LHS = (Yes (TBK w R equest . B*d_Sensors)) ) 

(©HYPO = Rcturn BAD Sensors) 

(@RHS = (Let ({ | BAD SENSORS |}.RTN_READINa) (TRUE)) 

(Stntegy (©CACTIONSON - FALSE;)) 

(Reset ({ | BAD_SENSORS | ) RTNREADING)) 
(Strategy (©C A CTIONSON * TRUE*)) 

(Execute ("BadSensorReadingsReturned")) ) ) 


(@RULE= RULE 90 1 RETRIE V E_SENSOR_P A RA METERS_FROM_S EN SO R_D AT A BA SE_ 

AND_RETURN_NOMINAL_DATA^TO_Too IBook 
(@LHS = (Yes (TBK_Request.Nominal_Sensor_Data)) 

(Retrieve ("SENSOR. nxp") 

(©TYPE = NXPDB;@FWRD = FALSE; ©UNKNOWN - TRUE;@PROPS = NAME, 
NOMINAL, TOLERANCE.ZERO LEVEL;©FIELDS = "NAME" , 

"NOMINAL", "TOLERANCE”, "ZERO_LEVEL’;©ATOMS= < jSENSORS| >;)) 
(©HYPO= Return NominalSeasorData) 

(©RHS = (Do (< | SENSORS jS .NOMINAL) (< | SENSORS | > .NOMINAL)) )) 


\ 


\ 

\ 

\ 

) 


CHAPTER VI 

FAULT DETECTION MODULE KNOWLEDGE BASE 


This chapter discusses the rule module for fault detection knowledge. Recall from 
chapter 1 that each task in the diagnostic process was separated into an individual 
knowledge base. The knowledge for the detection of faults in the ACTS transponder 
system is contained in the DETECT. tkb knowledge base. A complete listing of that 
module can be found in Appendix B. 

In section 1.3, the purpose of the fault detection task was defined as to detect any 
misbehavior in the performance of the ACTS transponder system. It was explained how 
this task involved the analysis of current sensor information in the form of qualitative 
descriptions for sensor readings. The knowledge required to detect a fault was then 
summarized as establishing a ’BAD" reading on any sensor in the transponder. 

The knowledge required to detect a fault, or determine that the transponder 
system is functioning properly is defined in Code Segment 6.1. First, the objects which 
represent the hypotheses of rules are defined. Then the two rules of the fault detection 
module are defined. 

rule _i oi represents the knowledge required to detect a fault. It first checks to 
see if the ToolBook Graphical User Interface (GUI) has requested fault detection. Then 
it scans the READING properties of all objects in the sensors class. It will fire if it finds 
any sensors who’s reading is ‘bad." Then, it executes an externally defined handler 
which communicates this result to the GUI. 
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Code Segment 6.1: Rules for the Detection of a Fault 


(©VERSION = 020) 

(©OBJECT = A_Fau lt_Ha s_Be e n_De te c ted 

(©PROPERTIES Value @T Y PE = Boolean; ) ) 

(©OBJECT— A_Fault_Has_Not_Been_Detected 

(©PROPERTIES = Value ©TYPE = Boolean; ) ) 

(©OBJECT = Transpond er JFunctioning_Properly 

(©PROPERTIES = Value ©TY PE = Boolean; ) ) 


(©RULE = RULE J 01 DETECTION_OF_A_FAULT 

(@LHS= (Yes (TBK_Request. Detection)) 

(Is ~ (<j SENSORS | >. READING) ("BAD") ) ) 

(©HYPO= A_Fault_Has_Been_Detected) 

(©RHS= (Execute ("FaultDetected")) ) ) 

(©RULE— RULEJ02_NON_DETECITON_OF_A_FAULT 

(@LHS= (Yes (TBKJRequest . Detection)) 

(Is ({ | SENSORS | }. READING) ("GOOD") )) 

(©HYPO= A_Fau lt_H a s_N ot_Be e n_Detecied) 

(©RHS= (Execute ("NoFauli Detec ted")) ) ) 


When NEXPERT" sends the message " FaultDetected " to the ToolBook" GUI, a 
handler defined there takes control from the NEXPERT application and the inference 
process is suspended. The user is informed that a fault has been detected within the 
transponder system and why this conclusion was reached. The user then has two options. 
He may either choose to continue the diagnostic process or stop and enter new data. 

If the user decides not to pursue the rest of the diagnostic process, the fault 
detection module is unloaded. The user is then returned to the sensor data input mode 
of the GUI. Should the user choose to continue with the rest of the diagnostic process, 
the GUI will then load and initiate the module for the next task, the fault isolation 
module. This module is discussed in the next chapter. 

RULEjoi can only report results to the ToolBook" GUI if a fault has been 
detected. This is because the right hand side actions of a rule will only be executed 
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when the rule fires. Furthermore, in atom-based inferencing, as used by NEXPERT", 
there is no ’ EL SE’ structure. This presents a problem in reporting to the GUI that the 
fault detection module has failed to detect a fault; implying that the transponder system 
is functioning properly. The result is the requirement of an additional rule. 

rule 102 represents the knowledge required to determine that the transponder is 
functioning properly. It first checks to see if the ToolBook Graphical User Interface 
(GUI) has requested fault detection. Then it scans the reading properties of all objects 
in the SENSORS class. It will fire only if it finds that all sensors are reporting "GOOD. " 
Then, it executes an externally defined handler which communicates this result to the 
GUI. 

The GUI handler for this message informs the user that the data he has entered 
is consistent with the proper functioning of the transponder system. The inference 
process is terminated, the fault detection module is unloaded, and the fidex kernel 
knowledge base is reset. The user then has the options to either end his session or 


evaluate a new set of data. 


CHAPTER VH 

FAULT ISOLATION MODULE KNOWLEDGE BASE 

This chapter discusses the rule module for fault isolation knowledge. Recall from 
chapter 1 that each task in the diagnostic process was separated into an individual 
knowledge base. The knowledge for the isolation of faults is contained in the 
ISOLATE. tkb knowledge base. A complete listing of that module can be found in 
Appendix C. 

In section 1.3, the purpose of the fault isolation task was defined as to isolate a 
suspected fault to a subsystem of the transponder. It was explained how this task also 
involved the analysis of current sensor information in the form of qualitative descriptions 
for sensor readings. The knowledge required to isolate a fault was then summarized as 
finding a subsystem who’s input sensor is reporting a * good ’ reading and who’s output 
sensor is reporting a "BAD" reading. 

Section 1.3 also discusses a subtask of sensor validation. This task was designed 
to identify the possibility of a faulty sensor. The knowledge required to validate sensor 
readings is the converse of that for isolating a fault. It can be summarizes as finding a 
subsystem who’s input sensor is reporting a "BAD" reading and who’s output sensor is 
reporting a "GOOD" reading. The following sections discuss the representation of 
knowledge required for each of these tasks. 
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7.1 Isolation of Faults to a Transponder Subsystem 
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The knowledge required to isolate a fault is defined in Code Segment 7.1. First, 
the objects which represent the hypotheses of rules are defined. Then the two rules of 
the fault isolation task are defined. 


Code Segment 7.1: Rules for the Isolation of a Fault 


(©VERSION = 020) 

(©OBJECT = lsolate_Faull_Symploms 

(©PROPERTIES = Value ©TYPE = Boolean; ) ) 


(©RULE = RULE_20 1 _ISOLATION_OF_FAULT_TO_SUBSYSTEM 

(@LHS= (Yea (TBK_Request. Isolation)) 

(Yes (Model Matrix_Switch_SubSystems) ) 

(Is ( < 1 SUBSYSTEMS | >~READING_IN) ("GOOD')) 

(1$ (< | SUBSYSTEMS j > ,READING_OUT) ('BAD'))) 

(@HYPO= Isolate_fault_Symptoms) 

(@RHS= (Let ( < | SUBSYSTEMS | > .ISOLATED) (TRUE) ) 

(CreateObject (< [SUBSYSTEMS! >) \ 

(| ISOLATED_SUB_SYSTEMS) 

(Execute ('FauHIsolaled')) ) ) 


(@RULE= RULE_202_ISOLATION_OF_FAULT_TO_FREQUENCY_COMPONENTS 

(@LHS= (Yes (TBK_Request. Isolation)) 

(Yea (Model_Matrix_Switch_SubSystems) ) 

(NotMember ({ | BAD_SENSORS | }) \ 

(<|PWR_SENSORS| >) ) 

Os ( < | BER_SENSORS*j > .READING) ('BAD'))) 

(@HYPO= Isolate_fault_Symptoms) 

(@RHS= (CreateObject (FREQ_COMPONENTS) \ 

([ISOLATED SUB_SYSTEMS) 

(Let (FREQ_COMPONENTS . ISOLATED) (TRUE) ) 

(Execute (“Faulllsolated’)) ) ) 


rule_201 represents the knowledge required to isolate a fault to one of the 
subsystems of the transponder. It first checks to see if the ToolBook Graphical User 
Interface (GUI) has requested fault isolation. Next, it verifies that the matrix switch 
paths have been modeled as subsystems of the transponder. Then it scans the reading JN 
and reading out properties of all objects in the subsystems class. It will fire if it finds 
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any subsystem who’s input reading is "GOOD’ and output reading is "BAD." If the rule 
fires, it flags the subsystem which met its conditions as isolated and creates a list of 
isolated _sub_systems in case more than one fault exists within the transponder. And 
finally, it executes an externally defined handler in the GUI. 

For this case, the purpose for sending this message to the GUI is simply to 
suspend the inferencing process and turn control over to the GUI. Recall from section 

5.5.2 that slot dynamics associated with the isolated property of subsystems effect the 
loading and initialization of subsystem diagnostic modules. 

rule_202 represents the knowledge required to isolate a fault to the group of 
frequency components in the transponder. It also first checks to see if the ToolBook 
Graphical User Interface (GUI) has requested fault isolation and that the matrix switch 
paths have been modeled as subsystems of the transponder. However, this rule scans the 
list of bad sensors that was created during the evaluation of sensor readings. It checks 
for the condition where no signal power level sensors report "BAD" readings, and at least 
one bit error rate register does. If it fires, it dynamically creates an object called 
freq components and attaches it to the isolated sub systems class. This new object 
will inherit subsystem properties, and its isolated flag is set to TRUE. And finally, as 
for r ule 201, it executes an externally defined handler which communicates these results 
to the GUI 

7.2 Validation of Sensorory Information 

The knowledge required to validate sensor readings is defined in Code Segment 
7.3. First, an object to represent the hypothesis of the rule is defined. Then the single 
rule of the sensor validation task is defined. rule_203 represents the knowledge required 
to determine that the detected fault may be the result of a faulty sensor. Like those for 
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fault isolation, it first checks to see if the ToolBook Graphical User Interface (GUI) has 
requested fault isolation and that the matrix switch paths have been modeled as 
subsystems of the transponder. 


Code Segment 7.2: Rules for the Validation of Sensors 


(©OBJECT = Validatc_Sensor* 

(©PROPERTIES = Value ©TYPE = Boolean; ) ) 


(©RULE = RULE_203 VALlDATE_SENSOR_DATA 

(©LHS = (Yes (TBK_Reque st. Isolation)) 

(Yes (Model Matrix_Switch_SubSystems) ) 

(Is (< (SUBSYSTEMS! > .READINGJN) ("BAD")) 

(Is (< | SUBSYSTEMS) > .READING OUT) ("GOOD"))) 

(©HYPO = Validate_Sensors) 

(©RHS= (CreaieObjecl (SENSOR_COMPONENTS) v 

( | ISOLATED_SUB_SYSTEMS | ) 

(Let (SENSOR_COMPONENTS . ISOLATED) (TRUE) ) 

(Execute ("SensorFault")) ) ) 


However, this rule scans the reading_in and reading_out properties of all 
objects in the subsystems class for the condition of any subsystem who’s input reading 
is "BAD" and output reading is "good. " If it fires, it dynamically creates an object called 
sensor components and attaches it to the isolatedsubsystems class. This new object 
will inherit subsystem properties, and its isolated flag is set to TRUE. And finally, it 
executes an externally defined handler which communicates these results to the GUI. 

The handler for the * SensorFault ” takes control and the NEXPERT inference 
process is suspended. The user is informed that the data he has entered is not consistent 
with the behavior of a fault in the transponder. He is also told that it is possible that this 
is the result of a faulty sensor; an invalid sensor reading. The user then has the options 
to reenter the sensory information, or to continue with the diagnostic process. Should 
he choose to continue, the remainder of the diagnostic process is pursued as discussed 
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in section 1.3. Recall from that section the special conditions that will be considered 
should a sensor fault be suspected. 



CHAPTER VHI 

FAULT DIAGNOSIS AND RESPONSE 
KNOWLEDGE BASES 

This chapter discusses the community of specialized diagnostic expert systems for 
the fault diagnosis and response tasks in the diagnostic process. Recall from chapter 1 
that each tas k in the diagnostic process was separated into an individual knowledge base. 
Furthermore, the rule knowledge required to diagnose faults associated with each 
subsystem of the transponder were also separated into specialized diagnostic knowledge 
bases. Listings for these knowledge bases can be found in Appendices D through G. 

These specialized diagnostic systems use knowledge which is rule-based and 
backward chaining in nature. The hypotheses for these rules represent the potential faults 
in the isolated subsystem. The order in which they are placed on the agenda is based on 
the history of the fault states. Maintaining this history permits FIDEX to pursue the 
most likely problems first. 

Each diagnostic system was also designed with an ability to perform inexact 
reasoning. This was done to overcome problems which resulted from limited information 
about the transponder’s performance. Such an ability was important in that the FIDEX 
system would often need to make a "guess" at the most likely fault state. This relies 
upon establishing incremental measures of belief or disbelief in rule conclusions. These 
two factors are then used to establish an overall confidence when a conclusion is 
supported by multiple rules. 
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The final task of fault response has been incorporated within the diagnostic 
modules for each subsystem. The present strategy for fault response is to provide 
recommendations for reconfiguring the components or sensors. Plans are to include the 
capability to reconsider fault diagnosis if the recommended action was ineffective. 
FIDEX would retain its past diagnosis, including recommendations, and reconsider the 
problem with information made available following the corrections to the transponder. 

There are several databases used by FIDEX. Seven of these are used to provide 
FIDEX a limited learning capability. FIDEX stores the failure history of the transponder 
subsystems system in associated database. Each known fault state is represented by a 
record that contains fields that represent the failure history of that fault state. Following 
diagnostics, FIDEX increments the history of the identified fault. This record keeping 
is used to direct the search strategy of future sessions toward the most likely faults. The 
next section discusses how this technique was implemented in all the diagnostic 
knowledgebases. 

8.1 Learning and Adaptive Search Strategies 

When NEXPERT’s inference mechanism needs to process a slot or rule 
hypothesis, it does so according to their inference priorities. This processing occurs by 
the order of highest-first. The value of a slot or hypothesis’s inference priority may be 
initialized from its default value of 1 to any integer between -32,000 and 32,000. 

Inference priorities can be dynamically changed to allow slots to be processed 
with different priorities at different times. This is Neuron Data’s mechanism for 
allowing the application to adapt itself to changing conditions. To implement this, a 
special slot called an inference slot is assigned to a slot’s inference priority. The 
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inference priority then takes on the value contained by the inference slot. This value is 

called the inference number of the atom. 

The search strategy is adaptive in that the priorities by which known fault states 
are placed on the agenda is based upon the values maintained in the history database. 
A class level property of all fault states is the integer iNF_dT. The value of this property 
is retrieved from the database when the diagnostic task is initialized. This property is 
then assigned to the value of the inference slot of the fault state hypothesis. When the 
diagnostic task establishes a known fault state, the value of its inference category is 
incremented accordingly. The updated value is then stored in the learning database. 

Recall the definition of infjcat property from section 4.4. This integer property 
is shared by all objects in the faultjtates class. As each object in that class represents 
a known fault state, this property is linked as the inference slot of fault state hypotheses. 
Code Segment 4.1 shows this linking for the AMP_CENERAL_FAJLURE (Amplifier General 
Failure) fault state. 


Code Segment 8.1: Linking of FAULT_STATE Inference Slots 


(<g) S LOT = AMPGENERALFAILURE. VERIFIED 

@ INF ATOM = AMPGENERALFAILURE.INFCAT ; ) 


One limitation of the NEXPERT inference mechanism is that if the value of a slot 
defined as an inference slot is unknown, NEXPERT will not try to evaluate a value for 
that slot. Therefore, the values of < \ fault_states\ >.inf_cat must be retrieved from 
the database before the diagnostic session begins. This initialization is effected by 
placing a rule on the agenda and forcing its evaluation. Code Segment 8.2 gives the 


definition of this rule. 
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Code Segment 8.2: Retrieval of < | FA UL T_STA TES | > .INF _CAT 


RULE 397 RETRIEVE_INFERHNCE_CATEGORIBS_FROM_DA TA B A SE 

(©LHS~ (Ye* (lniti*lize_lNF_CATi) ) 

(©HYPO = RetrieveJNF_CAT*_Frocn_DaUBaae) 

(©RHS = (Retrieve ("CHlRCVR.nxp") 

(©TYPE= NXPDB; 

©FWRD = FALSE; 

©UNKNOW = TRUE; 

©NAME= ’ < j FAULT_STATES j > * 

©PROPS = INF_CAT; 

©FIELDS = *INF_CAT";) ) ) ) 


During the initialization of a diagnostic module (ie. the channel 1 receiver 
subsystem diagnostic module in Code Segment 8.2), a value of true is volunteered for 
Initialize JNFJCATS. This places rule J 97 on the agenda and causes it to fire. The right 
hand side action then retrieves all inference category values form the designated database. 
In short, this discussion has addressed the recalling of inference categories from previous 
sessions with FIDEX. The final topic of this section is to address how FIDEX stores, 
or learns, about new inference categories for its fault state hypotheses. 

During the initialization of diagnostic knowledge bases, the IC actions associated 
with slots are disabled, @cactionson= false,- . Once the initialization process has 
completed, they are enabled again, @cactionson= true,- . This allows changing the 
value of a fault state’s infjoat slot to trigger the saving of a new inference category. 


Code Segment 8.3: Storing < \FAULT_STATES\ >.INF_CAT 


(©SLOT = FAULT_STATES . INFCAT 

(©CACTIONS = (Write ("CHlRCVR.nxp") 

(@TYPE= NXPDB; 
©FWRD= FALSE; 
©UNKNOW « TRUE; 
©PROPS = INFCAT; 
©FIELDS = *INF_CAT"; 
©ATOMS = SELF;) ) 


) 


) 
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Code Segment 8.3 shows how changing the value of any fault jtates inference 
category will result in that new value being written to the learning database. The values 
for the inference category are incremented by rules which support the fault state 
hypotheses. Code Segment 8.4 gives an example of such a rule. 


Code Segment 8.4: Incrementing < \FAULT_STATES\ > .lNF^CAT 


(®RULE« RULE 301 ATTE>HJATORJ5ETTING_ERROR 

(@LHS« (> ~ (IFPC_ATTN_1 .SETTINGERROR) (20)) 

(@HYPO= ATTENUATOR SETTING_ERROR. VERIFIED) 

«3>RHS» (Do (ATTENUATOR_SETTING_ERROR.INF_CAT + 1) ' 

(ATTENUATOR SETTING ERROR . INF CAT)) ) ) 


Code Segment 8.4 shows a rule that supports a fault state hypothesis that an IFPC 
attenuator has been set wrong. If this rule fires, its action will add 1 to the value of the 
inference category for the fault state attenuator seiting error. 

8.2 Subsystems Diagnostic Modules 


The operation of all the diagnostic modules is identical. Therefore, they will be 
discussed together. Complete listings may be found in the appendices. The following 
discussion will be in a general sense for all fault states. 

Again, each known fault state is represented by an object attached to the class of 
fault states in the object space of the diagnostic expert systems. After initialization, 
a suggestion is made that all fault states are to be verified, @suggestlst= 
< | fault_states\ >. verified. This suggestion places all fault states on the agenda. This 
is, in fact, an ordered list. According to the discussion of the previous section, the order 
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by which they are placed on the agenda will be based on the values of their inf_cat 
properties. 

The inference strategy used in the diagnostic process to this point has been 
forward chaining, or data driven. Now, the strategy for diagnosing fault states turns to 
backward chaining. Each fault state hypothesis is taken from the agenda, in turn, and 
pursued exhaustivly. Associative rule knowledge which supports each hypothesis will 
be evaluated in an attempt to conclude the existence of a predefined fault state. 

As the symptoms for these hard coded failure modes are pursued, evidence is also 
accumulated toward belief in, or rejection of, cumulatively associative and abstract fault 
states. Once the entire list has been evaluated, the fault state with the highest confidence 
factor is then presented as the diagnosed fault. The mechanisms of this inexact reasoning 
were discusses in several previous chapters. 

Again, as discussed in previous chapters, it is possible that the entire list be 
evaluated and no fault state indicate sufficient certainty. It is here where the 
accumulation of evidence at the abstract, or class, level becomes significant. FIDEX is 
able to recover from its failure to diagnose the fault state by presenting a classification 
of faults as the diagnosed fault. This is to say, FIDEX has the capacity to offer 
conclusions of the form: "The observed symptoms do not correspond to any known fault 
states of the transponder system. However, they do appear to be consistent with those 
of an amplifier failure. " 

Another important aspect of the architecture of the fault diagnostic modules is the 
facility with which diagnostic knowledge may be maintained. As the experience of the 
SITE personnel grows, and more knowledge is gained about the failure modes of the 
transponder, this knowledge can be appended to the knowledge bases by two simple 
manners. First, should more knowledge be gained about an existing fault, new rules may 
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be added. By attaching these new rules to the existing fault state hypotheses, they will 
automatically be incorporated into the inference strategy of the diagnostic module. 

Should a new fault state be discovered, the procedure is slightly more involved, 
but not more complex. A new fault state can be added to a diagnostic module by first 
creating an object to represent it and attaching that object into the faultjtates 
hierarchy. Then as discussed earlier, any rule knowledge which supports that new fault 
state can be encoded into the inference strategy by attaching it to the new hypothesis. 



CHAPTER IX 

SUMMARY OF RESEARCH 


FIDEX, the Fault Isolation and Diagnosis Expert System, was the result of a 
research contract with the National Aeronautics and Space Administration (NASA), 
Lewis Research Center, in Cleveland Ohio. It was designed to provide intelligent 
computer diagnostics for a Ka-band satellite transponder system, as part of the Advanced 
Communication Technology Satellite (ACTS) System. The overall goal of this research 
was to enhance the reliability of the satellite by demonstrating the application of expert 
system technologies as a means for providing the transponder with an autonomous 
diagnosis capability. 

The results of this research were more than just the development of a prototype 
diagnosis expert system. The frame-based approach that was taken proved that 
hierarchical structures are the best means for representing complex structures such as the 
satellite’s: subsystems, components, sensors, and fault states. Furthermore, FIDEX 
demonstrated that integrating these hierarchical structures into a lattice provided a flexible 
representation scheme that greatly facilitated the maintenance of the system architecture. 

FIDEX’s ability to detect abnormalities in the sensors which provide information 
on the transponder’s performance proved effective for ruling out simple sensor 
malfunctions. However, The major strengths of the FIDEX system have appeared on 
two different fronts. 

First, FIDEX proved that inexact reasoning techniques, based on the 
incrementally acquired evidence, are effective means for overcoming limitations on the 
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availability of information. This approach enabled FIDEX to reason in an abstract sense, 
and thus recover from situations where no concrete diagnostic conclusion could be 
reached. Furthermore, the frame-based architecture which resulted for the 
implementation of these techniques greatly facilitates the matter of maintaining the 
knowledge which supports the diagnosis of fault states. 

The second major strength of the FIDEX system was that it demonstrated that a 
primitive databased learning ability was an effective approach to maintaining records of 
past diagnosis studies. This ability permitted FIDEX to adapt its diagnostic search 
strategies to search first for those faults which are most likely to occur. Moreover, as 
most diagnostic expert systems learn through adaptations of new diagnostic knowledge, 
FIDEX enhanced its intelligence by learning about the diagnostic process itself. 

In its present form, FIDEX is a prototype system that is practical for 
demonstration purposes only. However, its overall design, with its generic structures and 
innovative features, makes the FIDEX system an applicable example for other types of 
diagnostic systems. Furthermore, the stress placed on the maintainability of its 
architecture provides for future developments and expansions which encompass a wide 
range of possibilities. Primarily however, it is the hope of its developers that the FIDEX 
system will eventually be augmented into a fully autonomous diagnostic expert system. 
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APPENDIX A 

FIDEX KERNEL KNOWLEDGE BASE 


A.l Sensor Initialization Database 
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A.3 FIDEX Kernel Knowledge Base 


(3VERSI0N= 020) 

(3PROPERTY= AB aTYPE=Float; ) 

(8PROPERTY= AO 3TYPE=Float; ) 

(aPROPERTY= BAD aTYPE=Boolean; ) 

(3PROPERTY= Bad_Sensors aTYPE=Boolean;) 

(3PR0PERTY= BIAS_CURRENT aTYPE=Float; ) 

<3PR0PERTY= BIAS_VOLTAGE 3TYPE=Float; ) 

(3PR0PERTY= CF 3TYPE=F loat; ) 

<aPROPERTY= COMPONENT aTYPE=String; ) 

(aPROPERTY= COMPONENTJN aTYPE=String; ) 
(aPROPERTY= COMPONENT_IN_2 3TYPE=String; ) 
(apROPERTY= COMPONENT_OUT 3TYPE=String; ) 
(3PROPERTY- COMPONENT_OUT_2 aTYPE=String; ) 
(3PR0PERTY= CONFIDENCE aTYPE=String; ) 

(aPROPERTY= CONFIG aTYPE=String; ) 

(aPROPERTY= COUPLING aTYPE=Boolean; ) 

(apROPERTY= DATA aTYPE=Float; ) 

(aPROPERTY= DESCRIPTION 3TYPE=String; ) 

OPROPERTY= D I AGNOST I C_MOOUIE aTYPE=Boolean; ) 
OPROPERTY= DRAIN_VOLTAGE 3TYPE=Float; ) 
(3PR0PERTY= ERROR 3TYPE=Float; ) 

<3PR0PERTY= EVALUATED TYPE=Boolean; ) 

(aPROPERTY= FREQUENCY 3TYPE=F loat; ) 

OPROPERTY= FREQUENCY 2 aTYPE=Float; ) 

<aPROPERTY= FREQUENCY IN 3TYPE=Float; ) 
OPROPERTY= FREQUENCY_IN_2 3TYPE=Float; ) 

(3PROPERTY= FREQUENCY_OUT 3TYPE=Float; ) 
(3PR0PERTY= FREQUENCY_OUT_2 aTYPE=Float; ) 
(3PROPERTY= GAIN 3TYPE=Float; ) 

(3PR0PERTY= GAIN_2 3TYPE=F loat; ) 

(3PR0PERTY= GATE VOLTAGE aTYPE=Float; ) 
«PROPERTY= GOOD - aTYPE=Boolean; ) 

(3PROPERTY= HIGH 3TYPE=Boolean; ) 

(aPROPERTY= INF_CAT 3TYPE=Float; ) 

(aPROPERTY= ISOLATED aTYPE=Boolean; ) 

(aPROPERTY= LEVEL 3TYPE=String; ) 

(aPROPERTY= LEVEL IN aTYPE=String; ) 

(3PR0PERTY= LEVEL'OUT aTYPE=String; > 

(3PR0PERTY= LO_INPUT_FREQUENCY 3TYPE=F loat; > 
(3PR0PERTY= LO INPUT_POWER aTYPE=Float; ) 
(aPROPERTY= LO — UN I T aTYPE=String; ) 

(3PR0PERTY= LOU aTYPE=Boolean; ) 

(3PR0PERTY= MB 3TYPE=F loat; ) 

(3PROPERTY* HD 3TYPE=Float; ) 

(3PR0PERTY= MOOEL_GAIN 3TYPE=F loat; ) 

(3PR0PERTY= MOOEL_GAIN_2 3TYPE=Float; ) 
(aPROPERTY= MOOEL_POUER_IN 3TYPE=Float; ) 
(aPROPERTY= MOOEL_POWER_IN_2 aTYPE=Float; ) 
OPROPERTY= MODEL - POWER_OUT 3TYPE=Float;) 
(aPROPERTY= MODEL_POWER_OUT_2 aTYPE=Float; ) 
(3PR0PERTY= MODEL_SETTING 3TYPE=Float; ) 
(3PR0PERTY- NAME aTYPE=String; ) 

(aPROPERTY= NASA_ID aTYPE=String; ) 

<aPROPERTY= NOMINAL 3TYPE=Float; ) 

<aPROPERTY= NOM I NAL_B I AS_CURRENT 3TYPE=Float; ) 
OPROPERTY= NOM I NAL_B I AS_VOLT AGE 3TYPE=Float; ) 
(3PR0PERTY= NOM I N AL_DR A I N_VOLT AGE 3TYPE=Float; ) 
(3PR0PERTY= NOM I NAL_FREQUENCY 3TYPE=Float; ) 
(3PR0PERTY= NOM I NAL_FREQUENCY_2 aTYPE=Float; ) 
(aPROPERTY= NOM I NAL_FREQUENCY_I N 3TYPE=Float; ) 
<aPROPERTY= NOMI NAL_FREQUENCY_I N_2 3TYPE=Float; ) 
(3PR0PERTY= NOM I NAL_FREQUENCY_OUT 3TYPE=Float; ) 
(3PR0PERTY= NOMINAL_FREQUENCY_OUT_2 aTYPE=Float;) 
(aPROPERTY= NOMINAL_GAIN 3TYPE=Float; ) 
(3PR0PERTY= NOMI NAL_GATE_VOLTAGE 3TYPE=Float; ) 
OPROPERTY= NOM I NAL~LO_I NPUT_FREQUENCY3TYPE=F loat; ) 
(3PR0PERTY= N0MINAL - L0JNPUT_P0UER3TYPE=Float; ) 


(3PR0PERTY= NOMINAL_POUER_IN aTYPE=Float; ) 
(3PR0PERTY= NOM I NAL_POUER_I N_2 aTYPE=Float; ) 
(3PROPERTY= NOM I NAL_POWER_OUT aTYPE=Float; ) 
OPROPERTY= NOMI NAL_POUER - OUT_2 3TYPE=Float;) 
(3PROPERTY= Nominal_Sensor_Data 3TYPE=Boolean; ) 
<3PROPERTY= NOMINAL - SETTING aTYPE=Float; ) 
(3PROPERTY= OK aTYPE=Boolean; ) 

(3PROPERTY= POUERJN 3TYPE=F loat; ) 
(3PR0PERTY= POUERJN 2 aTYPE=Float; ) 
(3PR0PERTY= POUER OUT aTYPE=Float; ) 
(3PR0PERTY= POUER - OUT_2 aTYPE=Float; ) 
(3PROPERTY= READING alYPE'String;) 

(3PROPERTY= READING IN 3TYPE=String; ) 
(3PROPERTY= READ I NG_OUT aTYPE=String; ) 
(3PROPERTY= RTNJEVEL 3TYPE=Boolean; ) 
(3PR0PERTY= RTN_NOMINAL aTYPE=Boolean; ) 
(3PROPERTY= RTN READING aTYPE=Boolean; ) 
(3PR0PERTY= SENSOR JN aTYPE=String; ) 
(3PR0PERTY= SENSOR OUT aTYPE=String;) 
(3PR0PERTY= SETTING aTYPE=Float; ) 

(3PROPERTY= SETTING ERROR 3TYPE=Float; ) 
(3PR0PERTY= TOLERANCE 3TYPE=F loat; ) 
(3PROPERTY= TYPE aTYPE=String; ) 

(3PR0PERTY= VERIFIED 3TYPE=Boolean; ) 
(3PR0PERTY= ZERO 3TYPE=Boolean; ) 

(aPROPERTY= ZEROJEVEL 3TYPE=F loat ; ) 



(3CLASS= AMPLIFIER_FAULTS 
(aPROPERTIES= 

AB 

AD 

CF 

COMPONENT 
CONFIDENCE 
I N F_CAT 
MB 
MD 

NAME 

VERIFIED 

) 

) 

(3CLAS$= AMPLIFIERS 
(3PROPERTIES= 

BIA$_CURRENT 
BIAS VOLTAGE 
COMPONENT_IN 
COMPONENT_OUT 
DESCRIPTION 
DRAIN VOLTAGE 
FREQUENCY 
FREQUENCY IN 
FREQUENCY OUT 
GAIN 

GATE VOLTAGE 
MODEL GAIN 
MODEL~POWER IN 
mooel’pouer OUT 
NAME “ 

NASA ID 

NOMINAL BIAS CURRENT 
NOMINAL~BIAS VOLTAGE 

nominal“drain_voltage 

NOM I NAL_FREQUENCY 

NOMINAL FREQUENCY_IN 

nominal“frequency_out 

nominal'gain 

nominal”gate_voltage 

nominal“powerjn 

NOMINAL_POWER OUT 
POWER IN 

power'out 

) 

) 

(3CLASS= attenuator^faults 
(3PROPERTIES= 

AB 

AD 

CF 

COMPONENT 
CONFIDENCE 
INF_CAT 
MB “ 

MD 

NAME 

VERIFIED 

) 

) 

(aCLASS= ATTENUATORS 
(3PR0PERTIES= 

COMPONENT_IN 
COMPONENT_OUT 
DESCRIPTION 
FREQUENCY 
FREQUENCY IN 

frequencyjxjt 

GAIN 

MODEL GAIN 


MODEL POWER IN 

model’power out 
model“setting 
NAME “ 

NASA ID 

NOMINAL_FREQUENCY 
NOMINAL_FREQUENCY_IN 
NOMINAL FREQUENCYJXJT 

nominal“gain 

NOMINAL POWER_IN 
NOMINAL~POWERJXJT 

nominal"setting 
POWER IN 

power'out 

setting 

SETTING ERROR 

) 

) 

(3CLASS= BAD_SENSORS 

(3PR0PERTIES= 

RTN_READING 

) 

) 

(SCLASS= BER_REGISTERS 

<3PR0PERTIES= 

COMPONENT_IN 
COMPONENT OUT 
DESCRIPTION 
FREQUENCY 
FREQUENCY IN 
FREQUENCY OUT 
GAIN 

MODEL JJA IN 
MODEL POWER JN 
mooel“power OUT 
NAME 
NASA ID 

NOMINAL FREQUENCY 
NOMINAL'FREQUENCY IN 

nominal”frequency_out 

NOM I NAL~GA I N 
NOMINAL_POWER IN 
NOMINAL POWER OUT 
POWER_IN 
POWER_OUT 

) 

) 

(aCLASS= BER SENSORS 
(aSUBCLASSES= 

CHI BERs 
CH2~BER$ 

) 

(aPROPERTIES= 

DATA 

ERROR 

EVALUATED 

LEVEL 

NAME 

NOMINAL 

READING 

RTN LEVEL 

RTN~NOMINAL 

RTN READING 

TOLERANCE 

TYPE 

ZEROJ.EVEL 

) 

) 



(3CLASS= CERTA I NT Y_ANALY$ I S 

(£SUBCLASSES= 

FAULT_$TATES 

) 

(3PR0PERTIES= 

AB 

AD 

CF 

CONFIDENCE 

MB 

MD 

) 

) 

(3CLASS= CHl_BERs 

<3PR0PERTIES= 

DATA 

ERROR 

EVALUATED 

LEVEL 

NAME 

NOMINAL 

READING 

RTN_LEVEL 

RTN_NOMINAL 

RTN_READING 

TOLERANCE 

TYPE 

ZERO LEVEL 

) 

> 

<»CLASS= CH2 BERs 

(3PR0PERT IE$*= 

DATA 

ERROR 

EVALUATED 

LEVEL 

NAME 

NOMINAL 

READING 

RTN LEVEL 

rtn'nominal 

rtn“reading 

tolerance 

TYPE 

ZERO LEVEL 

) 

) 

(3CLASS= COMPONENTS 

(aSUBCLASSES= 

AMPLIFIERS 

ATTENUATORS 

LOCAL_OSCILLATORS 

RECEIVERS 

POWER_METERS 

BER_REGISTERS 

SWITCHES 

GaAsFETS 

TWTAS 

MIXERS 

) 

(3PR0PERTIES= 

COMPONENTJN 

COMPONENTJXJT 

DESCRIPTION 

FREQUENCY 

FREQUENCYJN 

FREQUENCYJXIT 

GAIN 

MODEL_GAIN 
MODEL POWER IN 


MOOEL POWER OUT 
NAME “ 

NASA_ID 

NOMINAL FREQUENCY 
NOMINAL~FREQUENCY_IN 
NOMINAL FREQUENCY_OUT 
NOMINAL~GAIN 
NOMINAL^POWER IN 
nominal”power_out 
POWER IN 

power"out 

) 

) 

(3CLASS= FAULT_STATE$ 
(aSUBCLASSES= 

AMPLIFIER FAULTS 
ATTENUATOR FAULTS 
GaAs_FET_F AULTS 
LO FAULTS 
MIXER_FAULTS 
RECEIVER FAULTS 
SWITCH_FAULTS 
TWTA FAULTS 

) 

<aPROPERTIES= 

AB 

AD 

CF 

COMPONENT 

CONFIDENCE 

INF_CAT 

MB 

MD 

NAME 

VERIFIED 

) 

) 

(3CLASS= GaAs_FET_FAULTS 
(aPROPERTIES= 

AB 

AD 

CF 

COMPONENT 
CONFIDENCE 
INF CAT 
MB ~ 

MD 

NAME 

VERIFIED 

) 

) 

(3CLASS= GaAsFETS 
<3PROPERTIES= 

COMPONENT_IN 
COMPONENT OUT 
DESCRIPTION 
DRAIN VOLTAGE 
FREQUENCY 
FREQUENCY IN 
FREQUENCY JXJT 
GAIN 

GATE VOLTAGE 
MODEL GAIN 
MODEL POWER _IN 
MODELJ>OWER_OUT 
NAME 
NASA ID 

NOMINAL DRAIN_VOLTAGE 

NOMINAL~FREQUENCY 

nominal~frequency_in 


NOMI NAL_FREQUENCY OUT 

NOMINAL_GAIN 

NOMINALJiATEJ/OLTAGE 

NOMI NAL JOWER J N 

NOM I NAL_POWER_OUT 

POWERJN 

POWER JXJT 

) 

) 

(3CLASS= LO FAULTS 
(3PR0PERT IES= 

A8 

AO 

CF 

COMPONENT 
CONFIDENCE 
INF CAT 
MB “ 

HD 

NAME 

VERIFIED 

) 

) 

<aCLASS= LOCAL OSCILLATORS 
<aPROPERTIES=" 

COMPONENT IN 
COMPONENT OUT 
COMPONENT_OUT 2 
DESCRIPTION 
FREQUENCY 
FREQUENCY IN 
FREQUENCY OUT 
FREQUENCY OUT 2 
GAIN 

MODEL GAIN 
MODEL POWERJN 
MOOEL*"*POWER_OUT 
NAME “ 

NASA_ID 

NOMINAL FREQUENCY 
NOMINAL JREQUENCYJ N 
NOMINAL“FREQUENCY_OUT 
NOM I NAL“F REQUENC Y JXJT_2 

nominal“gain 

NOM I NAL JOWER J N 
NOM I NAL_POWER_OUT 
NOMINAL J>OWER_OUT 2 
POWERJN 
POWERJXJT 
POWER_OUT_2 

) 

) 

(aCLAS$= MIXER_FAULTS 
(SPROPERTIES= 

AB 

AD 

CF 

COMPONENT 

CONFIDENCE 

INF_CAT 

MB 

HD 

NAME 

VERIFIED 

) 

) 


COMPONENT OUT 
DESCRIPTION 
FREQUENCY 
FREQUENCY IN 
FREQUENCY OUT 
GAIN 

LO INPUT FREQUENCY 
LOJNPUTJ>OWER 
LO UNIT 
MOOEL_GAIN 
MODEL POWERJN 
MODE L~P OWE R OUT 
NAME “ 

NASA ID 

NOMINAL FREQUENCY 
NOMINAL JREQUENCY^IN 
NOM I N AL_F REQUE N C Y_OUT 
NOM I NAL J5A I N 

NOMINAL LOJNPUT FREQUENCY 
NOMINAL“LO INPUT POWER 

nominal'power IN 
nominal“power_out 
POWERJN 
POWER OUT 

) 

) 

(3CLASS= POWER_METERS 
(3PR0PERTIES= 

COMPONENT IN 
COMPONENT JXJT 
DESCRIPTION 
FREQUENCY 
FREQUENCY IN 
FREQUENCY OUT 
GAIN 

MODEL_GAIN 
MODEL_POWER IN 
MODEL POWER OUT 
NAME 
NASA_ID 

NOMINAL FREQUENCY 
NOMINAL“FREQUENCY IN 

nominal"frequency_out 

nominal~gain 

NOMINAL POWER IN 
NOMINAL~POWER out 
POWERJN 
POWER OUT 

) 

) 

(OCLA$S= PWR_SENSORS 
(QPROPERTIES= 

DATA 

ERROR 

EVALUATED 

LEVEL 

NAME 

NOMINAL 

READING 

RTN LEVEL 

RTN~NOMINAL 

RTN READING 

TOLERANCE 

TYPE 

ZERO LEVEL 

) 

) 


(3CLASS= MIXERS 
(3PR0PERT IES= 

COMPONENT IN 



<3CLASS= RECE I VER_FAULTS 
(3PR0PERTIES 2 
AB 
AD 
CF 

COMPONENT 
CONFIDENCE 
INF CAT 
MB ” 

MD 

NAME 

VERIFIED 

) 

) 

(3CLAS$= RECEIVERS 
(©PROPERTIES 2 
COMPONENT IN 
COMPONENT_OUT 
DESCRIPTION 
FREQUENCY 
FREQUENCY IN 
FREQUENCYJDUT 
GAIN 

LO INPUTJREQUENCY 
LO"lNPUT POWER 
LO"UNIT 
MOOEL_GAIN 
MODEL POWER IN 
MOOEL~POWER~OUT 
NAME ” 

NASA ID 

NOMINAL FREQUENCY 
NOMINAL“FREQUENCY_IN 
NOMI NAL"FREQUENCY_OUT 
NOMINAL“GAIN 

nominal~lo INPUT_FREQUENCY 
NOM I NALlLO^I NPUT _POWER 
NOMINAL POWER JN 
NOMINAL POWER_OUT 
POWER IN 
POWER_OUT 

) 

) 

(©CLASS 2 SENSORS 
(©SUBCLASSES 2 
PWR SENSORS 

ber"sensor$ 

) 

(©PROPERTIES 2 

DATA 

ERROR 

EVALUATED 

LEVEL 

NAME 

NOMINAL 

READING 

RTN_LEVEL 

rtn~nominal 

RTN_READING 

TOLERANCE 

TYPE 

ZERO LEVEL 

) 

) 

(©CLASS 2 SUBSYSTEMS 
(©PROPERTIES 2 

DIAGNOSTIC MODULE 
ISOLATED 
LEVELJN 
LEVEL OUT 


NAME 

READING IN 
READING OUT 
SENSOR In 
sensor’out 

) 

) 

(©CLASS 2 SWITCH FAULTS 
(©PROPERTIES 2 
AB 
AD 
CF 

COMPONENT 
CONFIDENCE 
INF CAT 
MB " 

MD 

NAME 

VERIFIED 

) 

) 

(©CLASS 2 SWITCHES 
(©PROPERTIES 2 
COMPONENT IN 
COMPONENT"! N 2 
COMPONENT'OUT 

component"out 2 

DESCRIPTION 

FREQUENCY 

FREQUENCY 2 

FREQUENCYJN 

FREQUENCY IN 2 

frequency”out 

frequency”out_2 

GAIN 

GAIN 2 

MODEL GAIN 

MODEL'GAIN 2 

model"power_in 
mooel"power IN 2 
model”powerjxit 
model”power out_2 
NAME “ 

NASA ID 

NOMINAL FREQUENCY 
nominal'frequency 2 

NOMI NAL"FREQUENCY IN 
NOMINAL FREQUENCY IN_2 
nominal”frequency_out 
nominal"frequencyjxjt_2 
nominal'gain 

NOMINAL_POWER IN 
NOMINAL POWER IN 2 
NOMINAL"POWER OUT 
nominal”power_out_2 
POWER IN 
POWER~IN 2 
power“out 
POWER 0UT_2 

) 

) 

(©CLASS 2 TWTA_FAULTS 
(©PROPERTIES 2 
AB 
AD 
CF 

COMPONENT 

CONFIDENCE 

INF_CAT 

MB 


HO 

NAME 

VERIFIED 
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) 

) 


(3CLASS* TWTAS 
(3PR0PERTIES* 

COMPONENT JN 

COMPONENT JXJT 

DESCRIPTION 

FREQUENCY 

FREQUENCY IN 

FREQUENCYJXJT 

GAIN 

MOOELJjAIN 

model jowerjn 

HODEL_POWER_OUT 

NAME 

NASA ID 

NOMINAL FREQUENCY 
NOMINAL_FREQUENCY IN 
NOMINAL FREQUENCYJXJT 
NOMINAL~GAIN 
NOMINAL POWER_IN 
NOMINALJOWERJXJT 
POWER IN 
POWER JXJT 

) 

) 

(QOBJECT* BER 1 
(3CLASSES= 

CHI BERS 
ber“registers 

) 

<3PR0PERTIES= 

COMPONENT IN 
COMPONENT OUT 
DATA 

DESCRIPTION 

ERROR 

EVALUATED 

FREQUENCY 

FREQUENCYJN 

FREQUENCY OUT 

GAIN 

LEVEL 

MODEL_GAIN 

MOD E L_POWE R_ I N 

MODEL_POWER_OUT 

NAME 

NASAJD 

NOMINAL 

NOW I NAL_FREQUENCY 
NOMINALJREQUENCYJN 
NOMINAL_FREQUENCY OUT 
NOMINALJaAIN 
NOMINAL POWER_IN 
nominal"power_out 

POWER JN 
POWER JXJT 
READING 
RTN LEVEL 
RTN_NOMINAL 
RTNJEADING 
TOLERANCE 
TYPE 

ZERO LEVEL 

) 

) 


(30BJECT* BER_2 
(3CLASSES* 

CHl_BERs 
BER REGISTERS 

) 

^PROPERTIES* 

COMPONENT JN 

COMPONENT_OUT 

DATA 

DESCRIPTION 

ERROR 

EVALUATED 

FREQUENCY 

FREQUENCY IN 

FREQUENCYJXJT 

GAIN 

LEVEL 

MODELJjAIN 
MODEL POWER IN 

model“power!out 

NAME 
NASA ID 
NOMINAL 

NOMINAL FREQUENCY 

NOMINAL FREQUENCYJN 

NOMINAL'FREQUENCY OUT 

NOMINALJAIN 

NOMINAL POWER IN 

nominal“power_out 

POWER JN 

POWER JXJT 

READING 

RTNJEVEL 

RTN NOMINAL 

rtn“reading 

TOLERANCE 

TYPE 

ZERO LEVEL 

) 

) 



OOBJECT* BERJ3 
(aCLASSES= 

CHI BERs 
berIregisters 

) 

(9PR0PERTIES= 

COMPONENTJN 

COMPONENT_OUT 

DATA 

DESCRIPTION 

ERROR 

EVALUATED 

FREQUENCY 

FREQUENCY IN 

FREQUENCY JXIT 

GAIN 

LEVEL 

HOOEL_GAIN 
MODEL POWERJN 
mooelj>owerjxit 
NAME ” 

NASA_ID 

NOMINAL 

NOMINAL_FREQUENCY 

nominal"frequency_in 
nominal_frequency_out 
nominal_gain 
nominal power jn 
nominal_power out 
power in 
power~out 

READING 

RTN level 
rtn_nominal 

RTN READING 

TOLERANCE 

TYPE 

ZERO LEVEL 

) 

) 

(30BJECT- BER 4 
(9CLASSES= 

CH2_BERs 
BER REGISTERS 

) 

(9PR0PERTIES= 

COMPONENTJN 

COMPONENTJXJT 

DATA 

DESCRIPTION 

ERROR 

EVALUATED 

FREQUENCY 

FREQUENCY JN 

FREQUENCY_OUT 

GAIN 

LEVEL 

MOOEL_GAIN 
MOOEL_POWERJN 
MODEL_POWER OUT 
NAME ” 

NASA__ID 

NOMINAL 

NOM I NAL_FREQUENCY 
MOM I NAL_FREQUENCY_I N » 
NOM I NAL_FREQUENCY_OUT 
NOMINAL_GAIN 
NOMINAL POWER_IN 
NOMINAL _ POWER_OUT 
POWER IN 

powerjxjt 

READING 


RTN LEVEL 
RTN~NOMINAL 
RTN READING 
TOLERANCE 
TYPE 

ZERO_LEVEL 

) 

) 

(30BJECT= BER 5 
<3CLASSES= 

CH2 BERS 
BER~REGISTERS 

) 

<3PR0PERTIES= 

COMPONENT IN 
COMPONENT OUT 
DATA 

DESCRIPTION 

ERROR 

EVALUATED 

FREQUENCY 

FREQUENCY IN 

FREQUENCY OUT 

GAIN 

LEVEL 

MODEL GAIN 

MODEL~POUER IN 

MODEL~POWERJXJT 

NAME 

NASA_ID 

NOMTNAI 

NOMINAL FREQUENCY 

NOMINAL FREQUENCY IN 

NON I NAlIfREQUENCY_OUT 

NOMINAL_GAIM 

NOMINAL POWER IN 

NOMINAL POWER OUT 

POWER_IN 

POWER OUT 

READING 

RTN LEVEL 

RTN~NOMINAL 

RTNJIEADING 

TOLERANCE 

TYPE 

ZERO_LEVEL 

) 

) 

(30BJECT= BER 6 
CaCLASSES= 

CH2_BERs 
BER REGISTERS 

) 

(3PROPERTIES= 

COMPONENT IN 

COMPONENT~OUT 

DATA 

DESCRIPTION 

ERROR 

EVALUATED 

FREQUENCY 

FREQUENCY IN 

FREQUENCY~OUT 

GAIN 

LEVEL 

MOOEL_GAIN 
MODEL_POWER IN 
MODEL_POWER_OUT 
NAME ” 

NASA_ID 

NOMINAL 
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NOMINAL JREQUENCY 
NOMINAL FREQUENCY IN 

nominal jreguencyjxjt 

NOMINALJ5AIN 

NOMINALJ>OUERJN 

NOM I NAL POWER OUT 

POWER JN 

POWER JXJT 

READING 

RTN JEVEL 

RTN_NOMINAL 

RTNJEADING 

TOLERANCE 

TYPE 

ZEROJEVEL 

) 

) 

(30BJECT= CHlAMP 
(SCLASSES= 

SUBSYSTEMS 

) 

<3PR0PERTIES= 

D I AGNOST I C_MODULE 

ISOLATED 

LEVEL IN 

LEVEL~OUT 

NAME 

READINGJN 
READING OUT 
SENSOR In 
SENSOR OUT 

) 

) 

(30BJECT= CH1RCVR 
(&CLASSES= 

SUBSYSTEMS 

) 

(cDPROPERTIES= 

DIAGNOSTIC MODULE 

ISOLATED 

LEVEL IN 

level“out 

NAME “ 

READING IN 
READINGJXJT 
SENSOR_IN 
SENSOR JXJT 

) 

) 

(30BJECT= CH1UPX 
(3CLA$SES= 

SUBSYSTEMS 

) 

(3PR0PERTIES= 

D I AGNOST I C_MODULE 

ISOLATED 

LEVELJN 

LEVEL JXJT 

NAME “ 

READINGJN 
READINGJXJT 
SENSOR_IN 
SENSOR JXJT 

> 

> 


(30BJECT= CH2AMP 
OCLASSES= 

SUBSYSTEMS 

) 

(3PR0PERTIES= 

DIAGNOSTIC_MODULE 

ISOLATED 

LEVEL IN 

level“out 
NAME ~ 

READING_IN 
READING OUT 
SENSORJN 
SENSOR JXJT 

) 

) 

(S)OBJECT= CH2RCVR 
(3CLASSES* 

SUBSYSTEMS 

) 

(aPROPERTIES= 

D I AGNOST I C J40DULE 

ISOLATED 

LEVEL IN 

LEVEL"OUT 

NAME ” 

READING IN 
READING~OUT 
SENSORJN 
SENSOR OUT 

) 

) 

(aOBJECT= CH2UPX 
<aCLASSES= 

SUBSYSTEMS 

) 

^PROPERTIES* 

D I AGNOST I CJIODULE 

ISOLATED 

LEVEL IN 

LEVEL OUT 

NAME " 

READING IN 
READING OUT 
SENSORJN 
SENSORJXJT 

) 

) 

(30BJECT* CURRENT ^COMPONENT 

(aPROPERTIES= 

COUPLING 

NAME 

) 

) 

(aOBJECT= CURRENT FAULT 
^PROPERTIES* 

NAME 

) 

) 

(30BJECT* CURRENT SENSOR 
<aPROPERTIES= 

NAME 

) 

) 

(30BJECT* CURRENT_SUBSYSTEM 
(3PROPERTIES* 

LEVEL IN 


LEVELJXJT 

NAME 

READINGJN 

READINGJXJT 

SENSOR_IN 

SENSOR_OUT 

) 

) 


NOMINAL FREQUENCYJXJT 

NOMINAL~GAIN 

NOMI NAL~GATE_VOLTAGE 

NOMI NAL_POWER_I N 

NOMINAL POWERJXJT 

POWER_IN 

POWER OUT 


(30BJECT= Evaluate_Certainty_Factors 
(aPROPERTIES= 

Value aTYPE=Boolean; 

) 

) 

<aOBJECT= GAASFET 
(3CLASSES= 

GaAsFETS 

) 

(3PR0PERTIES= 

COMPONENT_IN 

COMPONENT OUT 

DESCRIPTION 

DRAIN_VOLTAGE 

FREQUENCY 

FREQUENCY_IN 

FREQUENCYJXJT 

GAIN 

GATE VOLTAGE 
MODEL GAIN 
HODEL - POWER_IN 
MOOEL _ POWER_OUT 
NAME _ 

NASA ID 

NOMINAL DRA1NJ/OLTAGE 

NOMINAL'FREQUENCY 

NOMINAL _ FREQUENCY_IN 

nominal"frequency_out 

nominal"gain 

NOMINAL GATE_VOLTAGE 
NOM I NAL ~POWE R_ I N 
NOMINAL POWER_OUT 
POWER IN 
POUERJXJT 

) 

) 

(30BJECT= HPAPC_AMP_1 
(3CLASSES= 

AMPLIFIERS 

) 

(3PR0PERTIES= 

BIAS_CURRENT 

BIAS VOLTAGE 

COMPONENTJN 

COMPONENT_OUT 

DESCRIPTION 

DRAIN_VOLTAGE 

FREQUENCY 

FREQUENCY_IN 

FREQUENCY_OUT 

GAIN 

GATE VOLTAGE 

MOOEL_GAIN 

MOOEL_POWER_IN 

MOOEL_POUER_OUT 

NAME 

NASAJD 

NOMINAL_BIAS_CURRENT 
NOMINAL_BIAS VOLTAGE 
NOM I N AL_DRA I N_VOL T AGE 
NOM I NAL_FREQUENCY 
NOMINAL FREQUENCY_IN 


(30BJECT- HPAPCAMP 2 

<«JCLASSES= 

AMPLIFIERS 

) 

(3PROPERTIES= 

BIAS CURRENT 

BIAS _ VOLTAGE 

COMPONENT IN 

COMPONENT~OUT 

DESCRIPTION 

DRAIN_VOLTAGE 

FREQUENCY 

FREQUENCY IN 

FREQUENCYJXJT 

GAIN 

GATE VOLTAGE 
MODEL GAIN 
MOOEL~POWER_lN 
MODEL _ POWER OUT 
NAME ” 

NASA ID 

NOMINAL_BIAS CURRENT 
NOMINAL BIAS VOLTAGE 
NOM I N AL _ DR A I N_VOL T AGE 
NOMINAL~FREQUENCY 
NOMINAL _ FREQUENCY IN 
NOMI NAL _ FREQUENCY_OUT 
NOM I NAL_GA I N 
NOMINAL GATE_VOLTAGE 
NOMINAL~POWER IN 
NOMINAL POWER OUT 
POWER IN 
POWER OUT 

) 

) 

(S»OBJECT= HPAPC_ATTN_1 

OCLASSES= 

ATTENUATORS 

) 

<3PR0PERTIES= 

COMPONENT IN 

COMPONENT OUT 

DESCRIPTION 

FREQUENCY 

FREQUENCY_IN 

FREQUENCY_OUT 

GAIN 

MODEL GAIN 
MOOEL_POWER IN 
MODEL POWER_OUT 
MOOEL'SETTING 
NAME " 

NASA ID 

NOMINAL FREQUENCY 
NOMI NAL~ FREQUENCY_I N 
NOMINAL _ FREQUENCY_OUT 
NOMINAL_GAIN 
NOMINAL POWERJN 
NOMI NAL~POWER_OUT 
NOMINAL_SETTING 
POWER IN 
POWER OUT 
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SETTING 
SETTING ERROR 

) 

) 

(SOBJECT 2 HPAPC_ATTN_2 
(3CLASSES 2 

ATTENUATORS 

) 

(^PROPERTIES 2 
COMPONENTJN 
COHPONENT_OUT 
DESCRIPTION 
FREQUENCY 
FREQUENCY IN 
FREQUENCYJXIT 
GAIN 

MOOEL_GAIN 

MODEL_POUER_IN 

MODEL POUERJXJT 

model'setting 

NAME 

NASA ID 

NOMINAL_FREQUENCY 
NOMINAL FREQUENCYJN 
NOMINAL“FREQUENCY_OUT 
NOMINAL_GAIN 
NOMINAL POUER IN 
NOMINAL~POUER_OUT 

nominal"setting 

POUER IN 

power'out 

SETTING 
SETTING ERROR 

) 

) 

(30BJECT 2 HPAPC ATTN_3 
(SCLASSES 2 

ATTENUATORS 

) 

(SPROPERTIES 2 
COMPONENT IN 
COMPONENT OUT 
DESCRIPTION 
FREQUENCY 
FREQUENCY_IN 
FREQUENCY JXJT 
GAIN 

MODEL_GAIN 

MODEL_POUER_I N 

MODEL_POWER_OUT 

MODEL_SETTING 

NAME 

NASA ID 

NOMINAL_FREQUENCY 

NOMINAL FREQUENCY_IN 

NOMINAL“FREQUENCY_OUT 

NOMINAL_GAIN 

NOM I NAL_POUER_I N 

NOMI NAL_POUER_OUT 

NOMINAL_SETTING 

POWER_IN 

POWER__OUT 

SETTING 

SETTING_ERROR 

) 

) 


(S0BJECT 2 HPAPC_ATTN_4 
(3CLASSES 2 

ATTENUATORS 

) 

(^PROPERTIES 2 
COMPONENT IN 
COMPONENT'OUT 
DESCRIPTION 
FREQUENCY 
FREQUENCY IN 

frequency"out 

GAIN 

MODEL GAIN 
mooel“pouer IN 

MOOEL_POWER_OUT 
MODEL SETTING 
NAME ” 

NASA ID 

NOMINAL FREQUENCY 
nominal“frequency_in 
nominal’frequency out 
nominal’gain 
nominal pouerjn 
nominal~pouer out 

NOMINAL_SETTING 
POUER IN 

pouer“out 

SETTING 

setting error 

) 

) 

(30BJECT 2 IFPC AMP 1 
(SCLASSES 2 

AMPLIFIERS 

) 

(©PROPERTIES 2 
BIAS CURRENT 

bias“voltage 

COMPONENT IN 
COMPONENT OUT 
DESCRIPTION 
DRAIN VOLTAGE 
FREQUENCY 
FREQUENCY IN 
FREQUENCY'OUT 
GAIN 

GATE VOLTAGE 
MODEL GAIN 
MODEL“POUER IN 
MODEL_POUER OUT 
NAME 
NASA ID 

NOMINAL BIAS CURRENT 
NOMINAL~BIAS VOLTAGE 
NOMINAL DRAIN_VOLTAGE 

nominal“frequency 
nominal“frequency in 
nominal“frequency_out 
nominal'gain 

NOM I NALJ5ATE_V0LTAGE 
NOMINAL POUER IN 
NOMINAL~POUER_OUT 
POUER IN 

pouerjxjt 

) 

) 
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(SOBJECT 3 I FPC_AMP_2 
(©CLASSES 3 

AMPLIFIERS 

) 

(©PROPERTIES 3 
BIAS_CURRENT 
BIAS_VOLTAGE 
COMPONENT IN 
COMPONENTJXJT 
DESCRIPTION 
DRAIN_VOLTAGE 
FREQUENCY 
FREQUENCY_IN 
FREQUENCY_OUT 
GAIN 

GATE VOLTAGE 
MODEL GAIN 
MODE L_POWER_I N 
MOOEL_POWER_OUT 
NAME 
NASA ID 

NOMINAL BIA$_CURRENT 
NOMINAL’BIAS VOLTAGE 
NOMINAL DRAIN_VOLTAGE 
NOMINAL~FREQUENCY 

nominal~frequency in 
nominal’frequency out 

N0MINAL~GA1N 
nominal~gate_voltage 
nominal“power in 
nominal“power“out 
power in 
power“out 

) 

) 

(©OBJECT 3 ifpc AMP_3 
(©CLASSES 3 

AMPLIFIERS 

) 

(©PROPERTIES 3 

bias_current 

BIAS_VOLTAGE 

COMPONENT_IN 

COMPONENT_OUT 

DESCRIPTION 

DRAIN_VOLTAGE 

FREQUENCY 

FREQUENCY IN 

FREQUENCY~OUT 

GAIN 

GATE_VOLTAGE 
MODEL GAIN 
MODEL_POWER_IN 
MODEL_POWER_OUT 
NAME “ 

NASA ID 

NOMI NAL_B I AS_CURRENT 
NOMINAL_BIAS VOLTAGE 
NOM I NAL_DRA I N_VOLTAGE 
NOMlNAL_FREQUENCY 
NOM I NAL_FREQUENCY_I N 
NOM I NAL_FREQUENCY_OUT 
NOMINAL_GAIN 
NOMINAL_GATE_VOLTAGE 
NOM I NAL_POUER_I N 
NOM I NAL_POUER_OUT 
POWER_IN 
POWERJXJT 

) 

) 


(©OBJECT 3 I FPC_AMP_4 
(©CLASSES 3 

AMPLIFIERS 

) 

(©PROPERTIES 3 
BIAS CURRENT 

bias“voltage 

COMPONENT IN 
COMPONENTJXJT 
DESCRIPTION 
DRAIN VOLTAGE 
FREQUENCY 
FREQUENCY IN 
FREQUENCY“OUT 
GAIN 

GATEJ/OLTAGE 
MOOEL_GAIN 
MODEL POWERJN 
MODE L_P OWE R OUT 
NAME 
NASA ID 

NOMINAL BIAS CURRENT 
nominal!bias_voltage 
NOMINAL DRAIN VOLTAGE 
NOMINAL~FREQUENCY 
NOMINAL_FREQUENCY IN 
NOMINAL_FREQUENCY OUT 
NOMINAL GAIN 
NOMINAL“GATE VOLTAGE 
nominal“power IN 
nominal“power out 

POWER IN 

power'out 

) 

) 

(©OBJECT 3 IFPC_ATTN_1 
(©CLASSES 3 

ATTENUATORS 

) 

(©PROPERTIES 3 
COMPONENT IN 

component'out 

DESCRIPTION 
FREQUENCY 
FREQUENCY IN 
FREQUENCYJXJT 
GAIN 

MODEL GAIN 
MODEL“POWER IN 

mooelj>ower”out 

MODEL_SETTING 

NAME 

NASA ID 

NOMINAL FREQUENCY 
N0MINAL“FREQUENCYJN 

nominal“frequency_out 
nominal“gain 
NOMINAL POWER IN 

nominal'power out 
nominal'setting 

POWERJN 
POWER OUT 
SETTING 
SETTING ERROR 

) 

) 


(30BJECT= I FPC_ATTN_2 
(3CLASSES= 

ATTENUATORS 

) 

(3PR0PERTIES= 

COMPONENT_IN 

COMPONENT_OUT 

DESCRIPTION 

FREQUENCY 

FREQUENCYJN 

FREQUENCY_OUT 

GAIN 

HOOEL_GAIN 
MOOEL_POUER_IN 
MOOEL_POWER_OUT 
MODEL SETTING 
NAME “ 

NASA ID 

N0M1NAL_FREQUENCY 

NOM I NAL~FREQUENCY_I N 

NOM I NAL _ FREQUENCY_OUT 

NOMINAL_GAIN 

NOMINAL_POWER_IN 

NOMINAL_POUER_OUT 

NOMINAL_SETTING 

POWER IN 

POWER _ OUT 

SETTING 

SETTING ERROR 

) 

) 

(308JECT = I FPC_ATTN_3 

(3CLASSES= 

ATTENUATORS 

> 

(SIPROPERTIES= 

COMPONENT_IN 
COMPONENT OUT 
DESCRIPTION 
FREQUENCY 
FREQUENCY IN 
FREQUENCY OUT 
GAIN 

MODEL GAIN 
MODEL POWERJN 
MOOEL_POWER_OUT 

mooelIsetting 

NAME 

NASA_ID 

NOMINAL_FREQUENCY 

NOM I NAL_FREQUENCY_I N 

NOMINAL_FREQUENCY OUT 

NOMINAL_GAIN 

NOMINAL_POWER_IN 

NOM I N AL_POWE R_OUT 

NOMINAL_SETTING 

POWER_IN 

POWER_OUT 

SETTING 

SETTING ERROR 

) 

) 

(30B JECT= I FPC_ATTN_4 
(SCLASSES= 

ATTENUATORS 

) 

(3PR0PERTIES= 

COMPONENT_IN 

COMPONENT_OUT 

DESCRIPTION 

FREQUENCY 


FREQUENCY IN 
FREQUENCY OUT 
GAIN 

MODEL GAIN 
MODEL~POUER IN 
MOOEL~POWER OUT 
MODEL"SETTING 
NAME 
NASA ID 

NOMINAL_FREQUENCY 

NOMINAL_FREQUENCY_IN 

NOMINAL FREQUENCY_OUT 

NOMINAL GAIN 

NOMINAL POWER IN 

NOMINAL _ POWER_OUT 

NOMINAL~SETTING 

POWER_IN 

POWER_OUT 

SETTING 

SETT I NG_ERROR 

) 

) 

(SOBJECT= Model_Matrix_Swi tch_SubSyst 

<aPROPERTIES=~ 

Value aTYPE=Boolean; 

) 

) 

(30BJECT= MSWITCH 

(3CLASSES= 

SWITCHES 

) 

(SPROPERTIES= 

COMPONENT_IN 
COMPONENTS 2 
COMPONENTOUT 
COMPON E N T_OUT_2 
CONFIG 
DESCRIPTION 
FREQUENCY 
FREQUENCY 2 
FREQUENCY IN 
FREQUENCY IN 2 
FREQUENCY _ OUT 
FREQUENCY_OUT_2 
GAIN 
GAIN 2 
MODEL GAIN 
MODEL~GAIN_2 
MOOEL~POWER IN 
MOOEL_POWER_I N 2 
MODEL POWER_OUT 
MODEL~POWER_OUT_2 
NAME _ 

NASA ID 

NOMINAL_FREQUENCY 

NOMINAL_FREQUENCY_2 

NOMINAL_FREQUENCY_IN 

NOMINAL FREQUENCY_IN_2 

NOM I NAL^FREQUENC Y_OUT 

NOMINAL FREQUENCY_OUT_2 

NOMINAL~GAIN 

NOMINAL - POWER_IN 

NOM I NAL _ POWE R_ I N_2 

NOMI NAL _ POWER_OUT 

NOMI NAL _ POWER_OUT_2 

POWER IN 

POWER _ IN_2 

POWER_OUT 

POWER OUT 2 

) 

) 


(30BJECT= MSUITCH_CH11 
(SPROPERTIES= 

D I AGNOST I C_MODULE 

ISOLATED 

LEVEL JN 

LEVEL_OUT 

NAME 

READINGJN 
READ I NG_OUT 
SENSOR_IN 
SENSORJXJT 

) 

) 

OOBJECT- MSUITCH_CH12 
(3PR0PERTIES= 

D I AGNOST I C_MODULE 

ISOLATED 

LEVELJN 

LEVEL OUT 

NAME " 

READING IN 
READING JXJT 
SENSOR IN 
SENSORJXJT 

) 

) 

(aOBJECT= MSUITCH_CH21 
(SPROPERTIES= 

DIAGNOSTIC MODULE 

ISOLATED 

LEVEL IN 

LEVEL~OUT 

NAME 

READING IN 
READING OUT 
SENSOR In 
SENSOR OUT 

) 

) 

(30BJECT= MSWITCH JH22 

(3PR0PERTIES= 

D I AGNOST I C_MOOULE 

ISOLATED 

LEVEL IN 

LEVELJXJT 

NAME 

READINGJN 
READING_OUT 
SENSOR IN 
sensorjxjt 

> 

) 


MOOELPOWERJXJT 

NAME 

NASA ID 

NOMINALJREQUENCY 
NOMINALJREQUENCY IN 
NOMINALJREQUENCY JXJT 
NOMINAL GAIN 

NOMINAL _ LO INPUTJREQUENCY 

NOMINAL - LO _ INPUT_POWER 

NOMINAL - POWERJN 

NOM I NAL_POUER_OUT 

POWER IN 

POWER - OUT 

) 

) 

(SOBJECT= MULT 2 
<3CLASSES= 

MIXERS 

) 

(3PROPERTIES= 

COMPONENT IN 

COMPONENT OUT 

DESCRIPTION 

FREQUENCY 

FREQUENCY IN 

FREQUENCY - OUT 

GAIN 

LO INPUT FREQUENCY 
LO - 1 NPUT - POWER 
LO UNIT ” 

MODEL J5A IN 
MODEL_POWER IN 
MODEL POWER JXJT 
NAME “ 

NASA_ID 

NOMINALJREQUENCY 
NOMINAL FREQUENCY_IN 
NOM I NAL~FREQUENC Y_OUT 
NOMINAL JAIN 

NOMINAL LO INPUTJREQUENCY 
NOMI NALJOJ NPUT JOWER 
NOMINAL JOWER_IN 
NOMINAL POWER_OUT 
POWERJN 
POWER OUT 

) 

) 

(30BJECT= PM 0 
(3PR0PERT1ES= 

LEVEL 

NAME 

READING 

) 

) 


(30BJECT= MULT 1 

(9CLASSES= 

MIXERS 

) 

OPROPERTIES= 

COMPONENT IN 
COMPONENT JXJT 
DESCRIPTION 
FREQUENCY 
FREQUENCY JN 
FREQUENCY JXJT 
GAIN 

LO J NPUT JREQUENCY 
LOJ NPUT JOWER 
LOJJNIT 
MODEL GAIN 
MODEL POWER JN 


(30BJECT= PM 1 
<3CLASSES= 

POWER METERS 
PWR SENSORS 


) 

(3PR0PERTIES= 

COMPONENT IN 
COMPONENT OUT 
DATA 

DESCRIPTION 

ERROR 

EVALUATED 

FREQUENCY 

FREQUENCY JN 

FREQUENCY JXJT 

GAIN 
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LEVEL 

MOOEL_GAIN 

MODEL POWER_IN 

MOOEL~POWER_OUT 

NAME 

NASA_ID 

NOMINAL 

NOM I NAL_FREQUENCY 

NOM I NAL_FREQUENCY_I N 

NOMINAL_FREQUENCY_OUT 

NOMINAL_GAIN 

NOMINAL_POWER IN 

NOMINAL_POWER_OUT 

POWER_IN 

POWER OUT 

READING 

RTN LEVEL 

RTN NOMINAL 

RTN~READING 

TOLERANCE 

TYPE 

ZERO_LEVEL 

> 

) 

O06JECT= PM 2 
(3CLASSES= 

POWER METERS 
PWR_SENSORS 

) 

OPROPERTIES= 

COMPONENT IN 
COMPONENT OUT 
DATA 

DESCRIPTION 

ERROR 

EVALUATED 

FREQUENCY 

FREQUENCY IN 

FREQUENCY OUT 

GAIN 

LEVEL 

MODEL GAIN 
MOOEL - POWER_IN 
MOOEL j>OWER_OUT 
NAME " 

NASA_ID 

NOMINAL 

NOM I NAL_FREQUENCY 

NOMINAL _ FREQUENCY_IN 

NOMINAL_FREQUENCY_OUT 

NOMINAL_GAIN 

NOMINAL_POWER_lN 

NOM I NAL_POUER_OUT 

POWER_IN 

POWER_OUT 

READING 

RTN LEVEL 

RTNJJOM1NAL 

RTN_READING 

TOLERANCE 

TYPE 

ZERO LEVEL 


<aOBJECT= PM_3 
(3CLASSES= 

POWER_METERS 

PWR_SENSORS 

) 

(3PROPERTIES= 

COMPONENT IN 


COMPONENT OUT 
DATA 

DESCRIPTION 

ERROR 

EVALUATED 

FREQUENCY 

FREQUENCY IN 

FREQUENCY OUT 

GAIN 

LEVEL 

MOOEL_GAIN 

MOOEL POWER IN 

MOOEL~POWER_OUT 

NAME 

NASA ID 

NOMINAL 

NOMINAL FREQUENCY 

NOMINAL~FREQUENCY IN 

NOMINAL~FREQUENCY OUT 

NOMINALGAIN 

NOMINAL_POWER IN 

NOMINAL POWER_OUT 

POWER IN 

POWER_OUT 

READING 

RTN LEVEL 

RTNJIOMINAL 

RTN READING 

TOLERANCE 

TYPE 

ZERO LEVEL 

) 

) 

<30BJECT= PM 4 
(SCLASSES= 

POWER METERS 
PWR SENSORS 

) 

OPROPERTIES= 

COMPONENT IN 
COMPONENT OUT 
DATA 

DESCRIPTION 

ERROR 

EVALUATED 

FREQUENCY 

FREQUENCY IN 

FREQUENCY OUT 

GAIN 

LEVEL 

MODEL GAIN 
MODEL - POWER IN 
MOO E L~POWE R_OU T 
NAME “ 

NASAJD 

NOMINAL 

N0M1NAL_FREQUENCY 

NOMINAL FREQUENCY_IN 

NOM I NAL~ FREQUENCY_OUT 

NOMINAL~GAIN 

NOMINAL POWERJN 

NOMINAL_POWER_OUT 

POWER IN 

POWER_OUT 

READING 

RTN_LEVEL 

RTN NOMINAL 

RTN~READING 

TOLERANCE 

TYPE 

ZERO LEVEL 


(SUBJECT* PM_5 
(SCLAS$ES= 

POWER_METERS 

PWR_$ENSORS 

) 

<aPROPERTIES= 

COMPONENT JN 

COMPONENT_OUT 

DATA 

DESCRIPTION 

ERROR 

EVALUATED 

FREQUENCY 

FREQUENCY _IN 

FREQUENCYJXJT 

GAIN 

LEVEL 

MOOEL_GAIN 

kooel"power_in 
MODEL~POUER OUT 
NAME ~ 

NASAJD 

MHMT NAt 

NOMINAL FREQUENCY 

NOM I NAl_FREQUENCY_I N 

NOMINAL _ FREQUENCYJXJT 

NOHINAL GAIN 

NOHINAL POWERJN 

NOHINAL _ POWER_OUT 

POWER IN 

POWER~OUT 

READING 

RTN LEVEL 

RTN~NOHINAL 

RTN_READING 

TOLERANCE 

TYPE 

ZERO LEVEL 

) 

) 

(30BJECT= PH 6 
(3CLASSES= 

POWER METERS 
PWR SENSORS 

) 

(3PR0PERTIES= 

COMPONENT_IN 

COMPONENT_OUT 

DATA 

DESCRIPTION 

ERROR 

EVALUATED 

FREQUENCY 

FREQUENCY_IN 

FREQUENCY OUT 

GAIN 

LEVEL 

MOOEL_GAIN 
MOOEL_POWER_I N 
MOOEL_POWER_OUT 
NAME " 

NASAJD 

NOMINAL 

NOM I NAL_FREQUENCY 

NOMINAL_FREQUENCY_IN 

NOMINAL FREQUENCY_OUT 

NOMINAL~GAIN 

NOMINAL_POWER_IN 

NOMINAL_POWER OUT 

POWER IN 

POWER_OUT 

READING 


RTN LEVEL 

RTN~NOMINAL 

RTN_READING 

TOLERANCE 

TYPE 

ZERO LEVEL 

) 

) 

(30BJECT- PM 7 
OCLASSES= 

POWER_HETERS 
PWR SENSORS 

) 

<aPROPERTIES= 

COMPONENT IN 

COMPONENTJDUT 

DATA 

DESCRIPTION 

ERROR 

EVALUATED 

FREQUENCY 

FREQUENCY IN 

FREQUENCYJXJT 

GAIN 

LEVEL 

MODEL GAIN 
MODEL _ POWER_IN 
HODEL _ POWER OUT 
NAME ” 

NASAJD 

NOMINAl 

NOMINAL FREQUENCY 

NOMINAL FREQUENCY IN 

NOMINALJREQUENCY OUT 

NOMINAL_GAIN 

NOMINAL POWER IN 

NOMINAL _ POWER_OUT 

POWER IN 

POWER~OUT 

READING 

RTN LEVEL 

RTN~NOMINAL 

RTN _ READING 

TOLERANCE 

TYPE 

ZERO LEVEL 

) 

) 

<aOBJECT= PM 8 
(3CLASSES= 

POWER METERS 
PWR SENSORS 

) 

OPROPERTIES= 

COMPONENT_IN 

COMPONENT_OUT 

DATA 

DESCRIPTION 

ERROR 

EVALUATED 

FREQUENCY 

FREQUENCY JN 

FREQUENCY OUT 

GAIN 

LEVEL 

MOOEL GAIN 
MODEL POWERJN 
MOO E L~POWE R_OU T 
NAME “ 

NASA ID 
NOMINAL 


MOM I NAL_FREQUENCY 

MOM I NAL_FREQUENCY_I N 

NOMINAL_FREQUENCY_OUT 

NOMINAL GAIN 

NOMINAL POUER_IN 

NOMINAL_POWER_OUT 

POWER_IN 

POWER_OUT 

READING 

RTM_LEVEL 

RTN NOMINAL 

RTN~READING 

TOLERANCE 

TYPE 

ZERO LEVEL 

) 

) 

(30BJECT= RCVR_1 
(8CLASSES* 

RECEIVERS 

> 

OPROPERTIES= 

COMPONENT IN 

COMPONENTJXJT 

DESCRIPTION 

FREQUENCY 

FREQUENCY_IN 

FREQUENCY_OUT 

GAIN 

LO INPUT FREQUENCY 
LO - INPUT - POWER 
LO _ UNIT 
MODEL GAIN 
mooel”pouer IN 
MODEL POWER_OUT 
NAME ~ 

NASA ID 

NOMINAL FREQUENCY 
NOMINAL - FREQUENCY_IN 

nominalIfrequency OUT 
NOMINAL GAIN 

NOM I NAL J.O_I NPUT_FREQUENCY 
NOM I NAL_LO_lNPUT_POWER 

nominal”power_in 
NOMINAL_POWER OUT 
POWER IN 
POWER OUT 

) 

> 

(SOBJECT= RCVR_2 
<3CLASSES= 

RECEIVERS 

) 

(•(PROPERTIES 1 

COMPONENT_IN 

COMPONENT_OUT 

DESCRIPTION 

FREQUENCY 

FREQUENCY_IN 

FREQUENCY_OUT 

GAIN 

LO_INPUT FREQUENCY 
LO_INPUT _ POWER 
LO UNIT " 

MOOEL_GAIN 

MODEL POWER_IN 

mooel“power_out 

NAME 

NASA_ID 

NOMINAL FREQUENCY 
NOMI NAL~FREQUENCY_I N 


NOMINAL FREQUENCY_OUT 
NOMINALJ5AIN 

NOM I NAL_LO_I NPUT_FREQUENCY 
NOMINAL LO INPUT_POWER 
nominal!power_in 
NOMINAL POWER_OUT 
POWERIN 
POWER OUT 

) 

> 

(S)OBJECT= RCVR LO 

(3CLA$SES= 

LOCAL_OSCILLATORS 

) 

<3PR0PERTIES= 

COMPONENT IN 
COMPONENT - OUT 
COMPONENT~OUT_2 
DESCRIPTION 
FREQUENCY 
FREQUENCY IN 
FREQUENCY_OUT 
FREQUENCY OUT_2 
GAIN 

MODEL GAIN 
MOOEL _ POWER IN 
MODE L~POWE R_OU T 
NAME ” 

NASA ID 

NOMINAL FREQUENCY 
NOM I NAL~FREQUENC Y IN 
NOMINAL FREQUENCY OUT 
NOMINAL - FREQUENCY_OUT_2 
NOMINAL~GAIN 
NOMINAL POWER_IN 
NOM I NAL - POWE R_OUT 
NOMI NAL - POWER_OUT_2 
POWER IN 
POWER - OUT 
POWER _ OUT_2 

) 

) 

(S)OBJECT= Return BAD_Sensors 

OPROPERTIES= 

Value 8TYPE=Boolean; 

) 

) 

(S)OBJECT= Return Nominal_Sensor_Data 

(8PROPERTIES= 

Value 3TYPE=Boolean; 

) 

) 

(30eJECT= Sensor Level_Description 

OPROPERTIES= 

HIGH 

LOW 

OK 

ZERO 

) 

) 

(80B JECT= Sensor_Readi ng_Descr i pt i on 

(8PR0PERTIES= 

BAD 

GOOD 

) 

) 
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(aOBJECT= TBK_Request 
(aPROPERTIES= 

Bad Sensors 
NomTnal_Sensor_Data 

) 

) 

(80BJECT= TWTA 
(aCLASSES= 

TWTAS 

) 

OPROPERTIES= 

COMPONENT_IN 

COMPONENTJXIT 

DESCRIPTION 

FREQUENCY 

FREQUENCY_IN 

FREQUENCY_OUT 

GAIN 

MOOEL GAIN 
MOO El POUERJN 
MODEL - POWER_OUT 
NAME 
NASA ID 

NOM I NAl_FREQUENCY 
NOMINAL_FREQUENCY_IN 
NOM I NAL ~FREQUENCY_OUT 
NOMINAL GAIN 

nominalj>ouer_in 

NOMINAL_POWER_OUT 
POWER IN 
POWER~OUT 

) 

) 

<aOBJECT= UPX_LO 
(3CLASSES= 

LOCAL OSCILLATORS 

) 

(3PR0PERTIES= 

COMPONENT IN 

COMPONENT OUT 

COMPONENT_OUT_2 

DESCRIPTION 

FREQUENCY 

FREQUENCYJN 

FREQUENCY_OUT 

FREQUENCY OUT_2 

GAIN 

MOOEl_GAIN 
MOOEL_POWER_IN 
MOOEL_POWER OUT 
NAME 
NASA ID 

NOM I NAL_FREQUENCY 

NOMINAL_FREQUENCY_IN 

NOM I NAL_FREQUENCY_OUT 

NOM I NAL_FREQUENCY_OUT_2 

NOMINAL_GAIN 

NOMINAL POWER_IN 

NOMINAL~POWER OUT 

NOM I NAL_POWER_OUT_2 

POWERJN 

POWER_OUT 

POWER_OUT_2 

) 

) 

(3SLOT= BER_SENSORS.TYPE 
(3INITVAL= ''BER'*) 
OSOURCES= 

(RunTimeValue 

) 

) 


("BER")) 
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(3S LOT = CERTAINTY_ANALYSIS.AB 
(3INITVAL= 0.0) 

(3$0URCES= 

(RunTimeVaLue (0.0)) 

) 

(3CACTI0NS= 

(Do ( (SELF. AB-SELF.AD)/MIN(SELF.AB, SELF. AD)) 

) 


(SELF.CF) ) 


OSLOT= CERTAINTY_ANALY$IS.AD 
(31NITVAL= 0.0) 

(3S0URCES= 

(RunTimeVaLue (0.0)) 

) 

(3CACT IONS= 

(Do ((SELF. AB-SELF.AD)/MIN(SELF.AB, SELF. AD)) 

) 


(SELF.CF)) 


(S)SLOT= CERTAINTY_ANALYSIS.CF 
(3INITVAL= 0.0) 

(3S0URCES= 

(RunTimeVaLue (0.0)) 

) 

(3CACT IONS= 

(Do (SELF. NAME) (CURRENT JAULT .NAME) ) 

(Reset (Evaluate_Certainty_Factors) ) 

(Do (Eva Luate_Certainty_Fac tors) (EvaLuate_Certai nty_Factors) ) 

) 


(3SLOT= CERTAI NTY_ANALYSIS.MB 
(3INITVAL= 0.0) 

OS0URCES= 

(RunTimeVaLue (0.0)) 

) 

(3CACTI0NS= 

(Do (SELF .AB+SELF ,MB*(1 -SELF .AB) ) 
(Reset (SELF. MB)) 

) 

) 


(SELF.AB)) 


(3SL0T= CERTAINTY_ANALYSIS.MD 
(SINITVAL= 0.0) 

(3S0URCES= 

(RunTimeVaLue (0.0)) 

) 

(3CACTI0NS= 

(Do (SELF .AD+SELF.MD*( 1 -SELF .AD) ) 
(Reset (SELF ,MD) ) 

) 

) 


(SELF. AD)) 


(3SL0T= COMPONENTS. GAIN 
(3S0URCES= 

(Do (SELF. POWER_OUT-$ELF. POWER JN) 


(SELF. GAIN)) 


) 

(3CACTI0NS= 

(Do (SELF .POWER JN+SELF .GAIN) 


(SELF. POWERJXJT ) ) 


) 


) 


(3SL0T= COMPONENTS. MODEL_GA IN 


(3S0URCES= 

(Do (SELF .MOOEL JOWERJXJT 


-SELF. MODEL POWER JN) 


($ELF.MODEL_GAIN)) 


) 

(3CACTI0NS= 

(Do (SELF .MOOEL POWERJN+SELF .MODELJiAIN) 


(SELF. MODEL J>OWER_OUT)) 


) 


) 


(3SL0T= COMPONENT S . MODEL_POWER_I N 
<3S0URCE$= 

(Do (\SELF .COMPONENT^ N\.MODEL__POWER_OUT) 


) 

<3CACTI0NS= 

(Do (SELF .MOO E EMPOWER 


IN+SELF .MODEL_GAIN) 


) 


) 


( SELF . MOOEL_POWER_I N ) ) 


(SELF. MODE L _POWER_OUT ) ) 


O$L0T= COMPONENTS. MODEL_POWER_OUT 
(3S0URCES= 

(Do (SELF . MOD EL_POWER_ IN+SELF .MODEL_GAIN) 


(SELF. MOOEL_POWER_OUT ) ) 


) 

(3CACTIONS= 

(Do (SELF .MOO EL_POWER_OUT) 


(\SELF . COMPONE NT_OUT \ .MODE L_POUER _I N ) ) 


) 


) 


(3S LOT = COMPONENTS . POWER_I N 
(3S0URCES= 

(Do (\SELF . COMPONENT J N\ . POWER_OUT ) 


(SELF .POWER_IN)) 


) 

(3CACTI0NS= 

(Do (SELF. POWERJN+SELF. GAIN) 

) 


(SELF.POWERJXJT)) 


(aSLOT= COMPONENTS. POWER_OUT 
(aSOURCES= 

(Do (SELF. POWERJN+SELF. GAIN) 


(SELF.POWER_OUT)) 


) 

<aCACTIONS= 

(Do (SELF . POWER JXJT) 

) 


(\SELF. COMPONENT JXJT\ . POWER J N ) ) 


) 


<aSLOT= PUR SENSORS. TYPE 
(3INITVAL= “PM") 

OSOURCES= 

(RunTimeValue ("PM")) 

) 

) 


(3SL0T= SENSORS. DATA 
(3CACTI0NS= 

(Reset (SELF. ERROR)) 

(Reset (SELF. READING)) 

(Reset (SELF. LEVEL)) 

(Do (SELF. ERROR) (SELF .ERROR) ) 

(Do (SELF. READING) (SELF .READING) ) 

(Do (SELF. LEVEL) (SELF .LEVEL ) ) 

) 

) 

(8SLOT= SENSORS. ERROR 
(3S0URCES= 

(DO (SELF. DATA-SELF. NOMINAL) (SELF .ERROR ) ) 

) 

) 


(3SL0T= SENSORS. LEVEL 
(3S0URCES= 

(Do (SELF. NAME ) (CURRENT_SEN$OR . NAME ) ) 

(Reset ( Sensor J. eve l_De$cript ion. ZERO)) . 

(Do (Sensor Level J)escript ion. ZERO) (Sensorjevel J)escnpt lon.ZERO)) 

(Reset ( Sensor Jeve l _Desc r i pt i on . LOW ) ) . 

(Do (Sensor_Level_Description.LOU) (Sensor_LeveLJ)escription.LOW)) 

(Reset (Sensor Level Description. HIGH)) 

(Do (Sensor Jeve l _D esc ript i on. HIGH) (Sensor JevelJescript ion. HIGH)) 
(Reset ( Sensor Jeve l_Desc r i pt i on . OK ) ) . . 

(Do (Sensor_Level_Descr i pt i on. OK) (Sensor JevelJescript ion. OK)) 


) 

OCACTIONS= 
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» 


(Execute ("ReturnSensor Level") (3AT0MID=SEIF;3STRI NG =,, 3V(3SELF. LEVEL) 11 ; \ 


) 

OSLOT* SENSORS. NAME 

<aS<X ( Retrieve ("SENSOR. nxp") ( 3TYPE=NXPDB; 3FURD=FALSE ; SIUNKNOUN=TRUE ; 3PR0PS=NAME , \ 

NOMINAL, TOLERANCE, ZERO LEVEL;aFIELDS="NAME ,, ,\ 

"NOMINAL", "TOLERANCE", ,, ZERO_LEVEL' , ;aATOMS=SELF; \ 

)) 

) 

) 

<aSLOT= SENSORS. NOMINAL 

(aS0U Re^ r . ^ "SENSOR . nxp" ) (3TYPE=NXPDB ; 3FWRD=FALSE ; 3UNKN0WN=TRUE ; 3PR0PS=NAME , \ 

NOMINAL , TOLERANCE , ZERO_LEVE L;3F IE LDS="NAME" , \ 

"NOMINAL", "TOLERANCE" , "ZERO_LEVEL"; aATOMS=SELF; \ 

)) 

) 

(Execute ("ReturnNominalData") (aAT0MID=SELF;aSTRING="3V(3SELF.N0MINAL)";\ 

)) 

) 

) 

(3SL0T= SENSORS. READING 
(a$OURCES= 

(Do (SELF. NAME) (CURRENT_$ENSOR . NAME ) ) 

(Reset (Sensor Reading_Description.BAD) ) . . 

(Do ( Sensor_Readi ng_Descr i pt i on . BAD ) ($ensor_ReadingJ)escnption.BAD)) 

(Reset (Sensor Read ing_Descript ion. GOOD)) 

(Do (Sensor_Reading_Descript ion. GOOD) ( Sensor_Read 1 ng_Desc r l pt 1 on . GOOD ) ) 

) 

(Execute ("ReturnSensorReadi ng" ) (3AT0MID=SELF;3$TRING="3V(3SELF .READ I NG) n , \ 

)) 


) 


) 


(aSLOT= SENSORS . RTN_LEVEL 
(3CACTI0NS= 

(Execute ("ReturnSensorLevel") 

)) 

) 

) 

(3SL0T= SENSORS. RTN_NOM INAL 
(3CACTI0NS= 

(Execute ("ReturnNominalData") 

)) 

) 

) 


(3AT0MID=SELF;3STRING=»aV(3SELF. LEVEL )";\ 


(3AT0MID=SELF;3STRING=»aV(3SELF. NOMINAL )";\ 


(3SL0T= SENSORS. RTN_READ I NG 

(Execute ("ReturnSensorReadi ng") (3AT0MID=SELF;3STRING= ,i aV(3SELF .READING)";\ 

)) 

) 

) 

(3SLOT= SENSORS. TOLERANCE 

OSOURCES i^e ( H SENS oR.nxp") ( 3TYPE=NXPDB;3FWRD= FALSE ; 3UNKN0WN=TRUE ; 3PR0P$=NAME, \ 

NOM I NAL , TOLERANCE , ZER0_LEVEL;3F I ELD$="NAME" , \ 
»NOMINAL ,, ,"TOLERANCE ,, f H ZERO_LEVEL";aATOMS=SELF;\ 

)) 

) 

) 
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(aSLOT= SENSORS. ZERO_LEVEL 

<aS0< (RetMeve ( "SENSOR, nxp") (aTYPE=NXPDB;3FWRD=FALSE;aUNKN0WN=TRUE;aPR0PS=NAME,\ 
NON I NAL , TOLERANCE , ZER0_LEVEL;3F I ELDS="NAME» , \ 

»'NOH I NAL" , "TOLERANCE" , "ZERO_LEVEL" ; 3AT0MS=SELF ; \ 

)) 

) 

) 


<aSLOT= SUBSYSTEMS. ISOLATED 
(3CACTI0NS= 

(Execute ("Returnlsolation") 

) 

) 


(SATOMID=SELF;aSTRING="aV(aSELF.NAME)";)) 


(3SLOT= SUBSYSTEMS. LEVELJN 
(3SOURCES= 

(Do (\SELF.$EN$OR_IN\. LEVEL) (SELF.LEVELJN)) 

) 

) 


(3SL0T= SUBSYSTEMS. LEVEL^OUT 
OSOURCES= 

(Do (\SELF.SENSOR_OUT\. LEVEL) 

) 

) 


(SELF .LEVEL_OUT)) 


(3SL0T= SUBSYSTEMS. READ I NGJN 
(aSOURCES= 

(Do (\SELF.$ENSOR_IN\. READING) 

) 

) 


(SELF .READING_IN)) 


(3S LOT = SUBSYSTEMS. READ I NG_OUT 
(a$OURCES= 

(Do (\SELF. SENSOR JXJT\. READING) 

) 

) 


(SELF .READING_OUT)) 


OSLOT= SWITCHES. GAIN_2 
(aSOURCES= 

(Do (SELF .POWER_OUT_2- SELF .POWER_IN_2) 


<SELF.GAIN_2>> 


) 

✓ aPAPT mkK= 

(Do (SELF.POWERJN_2+SELF.GAIN_2) 

) 


(SELF .POWER_OUT_2)) 


) 


OSLOT= SWITCHES. MODEL_GAIN_2 
( 

) 

C 

) 

) 


(aSOURCES self mqoel_POWER_OUT_2-SELF .MOOEL_POWER_IN_2) ($ELF.MODEL_GAIN_2) ) 

(aCA (Do° N ( S SELF.MODEL - POWER_IN_2+SELF.MODEL_GAIN - 2) (SELF. MOD EL_POWER_OUT_2)) 


(3SL0T= BER_1 .NAME 

(3INITVAL= "BER_1") 

(3SOURCES= 

(RunTimeValue ( M BER_1 M )) 

) 

) 


(3SLOT= BER_2.NAME 

OINITVAL= "BER_2") 

( a^nuppFSs 

(RunTimeValue <"BER_2 M )) 

) 

) 
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(3SL0T= BER_3.NAME 

(3INITVAL= "BER_3") 

(^SOURCES- 

(RunTimeValue ( M BER_3")) 

) 

) 

<aSLOT= BER_4.NAME 

(aiMITVAL= M BER_4") 

<aSOURCES= 

(RunTimeValue < M BER_4 M )) 

) 

) 

<aSLOT= BER_5.NAME 

(aiNITVAL= ,, BER_5") 

(3S0URCES= 

(RunTimeValue (“BERKS' 1 )) 

) 

) 

(aSLOT= BER_6.NAME 

(aiNITVAL= "BER_6"> 

(3S0URCES= 

(RunTimeValue ( ,, BER_6 ,I >) 

) 

) 

(aSLOT= CHI AMP .D I AGNOST I C_MODULE 
(aiNITVAL= FALSE) 

(aSOURCES= 

(RunTimeValue (FALSE)) 

) 

(3CACTION$= 

(LoadKB ("CHlAMP.tkb") (3LEVEL=ENABLE; ) ) 

) 

) 

(a$LOT= CHI AMP. NAME 

(aiNITVAL= "CHlAMP") 

(3S0URCES= 

(RunTimeValue < "CHI AMP")) 

) 

) 

OSL0T= CH1AMP.SENS0RJN 
(aiNITVAL= ,, PM_5 n ) 

OS0URCES= 

(RunTimeValue ("PM_5")) 

) 

) 

OSL0T= CHI AMP . SENSOR_OUT 
(aiNITVAL= "PM_7") 

(3S0URCES= 

(RunTimeValue <"PM_7»)) 

) 

) 

(3SL0T= CHI RCVR . D I AGNOST I C_MODULE 
OINITVAL= FALSE) 

(3S0URCES= 

(RunTimeValue (FALSE)) 

) 

(3CACTI0NS= 

( LoadKB ( »CH 1 RCVR . t kb" ) ( 3LEVEL=ENABLE; ) ) 

) 

) 



(3SL0T= CHI RCVR. NAME 

(3INITVAL= "CHIRCVR") 

(RunT imeValue (“CHIRCVR")) 

) 

) 

(3SL0T= CHI RCVR . SENSOR_I N 
(3INITVAL= "PH_0") 

(MnitCFS: 

(RunT imeValue ("PM_0")) 

) 

) 

(3SL0T= CHI RCVR. SENSOR_OUT 
(3INITVAL= "PMJ") 
f a^mJPTFSs: 

(RunT imeValue ("PMJ")) 

) 

) 

<aSLOT= CH1UPX.DIAGN0STIC_M00ULE 
(3INITVAL= FALSE) 

(3sources= 

(RunT imeValue (FALSE)) 

) 

(3CACTI0NS= 

(LoadKB ("CHlUPX.tkb") (o)LEVEL=ENABLE; )) 

) 

) 

(3SL0T= CH1UPX.NAME 

OINITVAL= "CHIUPX" ) 

(aSOURCES= 

(RunTimeValue ("CHIUPX")) 

) 

> 

(3SL0T= CHIUPX. SENSORJN 
(aiNITVAL= "PM_3" ) 

(aSOURCES= 

(RunTimeValue ("PMJJ")) 

) 

) 

(3SL0T= CHI UPX . SENSOR_OUT 
(aiNITVAL= "PM 5 M ) 

(3S0URCES= 

(RunTimeValue ( ,, PM_5 1 *)) 

) 

) 

(3SL0T= CH2AMP .DIAGNOSTIC_MOOULE 
(aiNITVAL= FALSE) 

(aSOURCES= 

(RunTimeValue (FALSE)) 

) 

(aCACTIONS= 

(LoadKB ("CH2AMP. tkb") (SLEVEL=ENABLE; )) 

) 

) 

(3SL0T= CH2AMP .NAME 

(31NI TVAL= "CH2AMP" ) 

OS0URCES= 

(RunTimeValue ("CH2AMP")) 

) 

) 
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(a$LOT= CH2AMP.SENS0RJN 
(3INITVAL= ,, PM_6" ) 
casouRCEs= 

(RunTimeValue ( ,, PH_6 14 )) 

) 

) 

(3$L0T= CH2AMP . SENSOR_OUT 
<3INITVAL= M PM_8 M ) 

( 3 S 0 URCES= 

(RunTimeValue (“PM_8")) 

) 

) 

<aSLOT= CH2RCVR.DIAGN0STIC_M00ULE 
(aiNITVAL= FALSE) 

(aSOURCES= 

(RunTimeValue (FALSE)) 

) 

(3CACT IONS= 

(LoadKB ("CttfRCVR.tkb") OLEVEL=ENABLE; )) 

) 

) 

(3SL0T= CH2RCVR.NAME 

(3INITVAL= "CH2RCVR") 
fa<;niiRrFS= 

(RunTimeValue CCH2RCVR")) 

) 

) 

( 3 SL 0 T= CH 2 RCVR . SENSOR_I N 
( 3 INITVAL= n PM_O n ) 

(aSOURCE$= 

(RunTimeValue ( ,l PM_0“)) 

) 

) 

(3SL0T= CH2RCVR . SENSOR_OUT 
(aiNITVAL= , *PH_2 M ) 

(aSOURCES= 

(RunTimeValue ( ,, PH_ 2 ,, )> 

) 

) 

( 3 SL 0 T= CH 2 UPX . D I AGNOST I C_MODULE 
(aiNITVAL= FALSE) 

(3S0URCES= 

(RunTimeValue (FALSE)) 

) 

OCACTI0NS= 

(LoadKB ("CH2UPX.tkb‘') (3LEVEL=ENABLE; ) ) 

) 

) 

(3SL0T= CH2UPX.NAME 

(aiNI TVAL= "CH 2 UPX") 
rcicm iprF<;= 

(RunTimeValue ("CH 2 UPX")) 

) 

) 

(3SL0T= CH2UPX.SENSORJN 
(3INITVAL= n PM_4 u ) 

(3S0URCES= 

(RunTimeValue ( M PM_4")) 

) 

) 


(3SL0T= CH2UPX. SENSOR OUT 
(3INITVAL= “PH 6") 

(3S0URCES= 

(RunTimeValue ( ,, PM_6")) 

) 

) 

(aSLOT= HSWITCH. CONFIG 
(3S0URCES= 

(Execute (“RequestMatrixSwi tchConf ig“)) 

) 

) 

<aSLOT= HSU I T CH_CH 1 1 . D I AGNOST I C_HODULE 
(3INITVAL- FALSE) 

<aSOURCES= 

(RunTimeValue (FALSE)) 

) 

(3CACTI0NS= 

( LoadKB ( “HSWITCH . t kb“ ) (3LEVEL=ENABLE ; ) ) 

) 

) 

(3$L0T= HSWITCH_CHl 1 .NAME 
(aiNITVAL= "MSWITCH") 

^a<;r»tiprF^= 

(RunTimeValue (“MSWITCH")) 

) 

) 

(3SL0T= MSWITCH CH1 1 .SENSORJN 
(3INITVAL= ~“PMJ») 

OSOURCES= 

(RunTimeValue ("PMJ")) 

) 

) 

(aSL0T= MSWITCH CHI I.SENSORJXJT 
(aiNITVAL= “PM _3") 

(3SOURCES= 

(RunTimeValue ( ,, PM_3“)) 

) 

) 

(3SL0T= MSUI TCH_CH12.DI AGNOST I C_MOOULE 
(aiNITVAL= FALSE) 

(3SOURCE$= 

(RunTimeValue (FALSE)) 

) 

(3CACT IONS= 

(LoadKB (“MSWITCH. tkb") (aLEVEL=ENABLE; )) 

) 

) 

(3SL0T= MSWITCH_CH12.NAME 
(3INITVAL= “MSWITCH") 

(aSOURCES= 

(RunTimeValue (“MSWITCH")) 

) 

) 

(3SLOT= MSWITCH_CH12 .SENSOR JN 
OINITVAL= "PMJ") 

(3S0URCES- 

(RunTimeValue (“PMJ")) 

) 

) 

(3SL0T= MSWITCH__CHl2.SENS0R_pUT 
(3INITVAL= “"PM_4") 

(3SOURCES= 

(RunTimeValue ("PM_4")) 


)) 
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(aSLOT= MSUITCH_CH21 .DIAGNOSTIC_MODULE 
(aiNITVAL= FALSE) 

(aSOURCES= 

(RunTimeValue (FALSE)) 

) 

( a)C ACT IONS= 

(LoadKB ("MSWITCH. tkb") (SLEVEL=ENABLE; ) ) 

) 

) 

(S$LOT= MSWITCH_CH21 .NAME 
(SIN I TVAL = "MSWITCH") 

(SSOURCES= 

(RunTimeValue ("MSUITCH")) 

) 

) 

(S$LOT= MSWITCH CH21 .SENSOR_IN 
(SINITVAL= “ "PM_2") 

TasnURCES= 

(RunTimeValue ("PM_2")) 

) 

) 

(SSLOT= MSWITCH CH21 .SENSOR _OUT 
(SINITVAL= " "PM_3") 

(SSOURCES= 

(RunTimeValue ("PM_3" )) 

) 

) 

(SSLOT= MSWITCH CH22 .DIAGNOSTIC_MODULE 
(SINITVAL= “FALSE) 

(S$OURCES= 

(RunTimeValue (FALSE)) 

) 

(SCACTIONS= 

( LoadKB ( "MSWITCH . t kb" ) ( SLEVEL=ENABLE; ) ) 

) 

) 

(SSLOT= MSWITCH_.CH22.NAME 
(SI NI TVAL= "MSWITCH") 

(RunTimeValue ("MSWITCH")) 

) 

) 

(SSLOT= MSWITCH_CH22.SENS0R_I N 
(SINITVAL= "PM_2") 

(SSOURCES= 

(RunTimeValue ("PM_2")) 

) 

) 

(SSLOT= MSW I TCH_CH22. SENSOR J3UT 
(SINITVAL= "PM_4") 

(SSOURCES= 

(RunTimeValue ("PM_4")) 

) 

) 

(SSLOT= PM_0. LEVEL 

(SI NITVAL= "OK") 

(SS0URCES= 

(RunTimeValue ("OK")) 

) 

) 


(3SL0T= PH_O.NAME 

(aiNITVAL= "PKO") 

/ocrw jdpFS= 

(RunTimeValue <»PM_0»)> 

) 

) 

<aSLOT= PM_0. READING 

(3INITVAL= "GOOD") 

OSOURCES= 

(RunTimeValue (“GOOD”)) 

) 

) 

(3SL0T= PMJ.NAME 

(3INITVAL= “PHJ") 

(3S0URCES= 

(RunTimeValue ("PM_1")) 

) 

) 

OSLOT= PM_2 .NAME 

(3INITVAL= • i PM_2 ,, > 

(3S0URCES- 

( RunTimeValue ("PM_2“)) 

) 

) 

(aSLOT= PM_3 . NAME 

(3INITVAL= ,, PHJ3 M ) 

(3S0URCES= 

(RunTimeValue ( ,, PM_3 ,, )> 

) 

) 

(aSLOT= PM 4. NAME 

(3INITVAL= »PM4“> 

(3S0URCES= 

(RunTimeValue ( ,, PM_4 M )) 

) 

) 

OSL0T= PM_5 .NAME 

(3INITVAL= ,, PNJ5 ,, > 

(3S0URCES= 

(RunTimeValue ("PM_5 M )) 

) 

) 

(3SL0T= PM 6. NAME 

(3INITVAL= "PM_6 H ) 

(3SOURCES= 

(RunTimeValue ("PM_6")) 

) 

) 

(3SL0T= PM_7.NAME 

(3INITVAL= ,, PM_7 ,, ) 

(3S0URCES= 

(RunTimeValue ( M PM_7 M )> 

) 

) 

OSL0T= PM_8.NAME 

(3INITVAL= ,, PM_8 ,, ) 

(RunTimeValue ("PM_8")) 

) 

) 
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(3RULE= RULE_029_QUALIFICATION_OF_CONFIDENCE_REJECTED 
(3LHS= 

(<= (\CURRENT_FAULT .NAME\.CF) (-0.9)) 

) 

(3HYP0= Evaluate_Certainty_Factors) 

(3RHS- 

(Let (\CURRENT_FAULT.NAME\. CONFIDENCE) ("REJECTED”)) 

(Let (\CURRENT_FAULT.NAME\. VERIFIED) (FALSE)) 

) 

) 

( 3RULE= RULE_028__QUAL I F I CAT I ON_OF_CON F I DENCE VERY_I MPROBABLE 

(3LH$= 

(<= (\CURRENT_FAULT .NAMEX.CF) (-0.75)) 

(> (\CURRENT_FAULT .NAMEX.CF ) (-0.9)) 

) 

(3HYP0= Eva Luate_Certainty_Fac tors) 

/ Jjn UC — 

(Let (\CURRENT_FAULT.NAME\. CONFIDENCE) ("VERY_IHPROBABLE")) 

) 


(3RULE= RULE_027 QUAL I F I CAT I 0N_0F_C0N FI DENCE IMPROBABLE 

(3LHS= 

(<= ( \CURRENT_FAULT . NAME\ . CF ) (-0.5)) 

(> (\CURRENT_FAULT .NAME\.CF) (-0.75)) 

) 

(3HYPO= Evaluate_Certainty_Factors) 

(QRHS= 

(Let (\CURRENT_FAULT.NAMEX. CONFIDENCE) ("IMPROBABLE")) 

) 

) 

(SRULE= RULE 026 QUAL I F I CAT I ON_OF_CON F I DENCE UNL I KELY 

(a)LHS= 

(<= (\CURRENT_FAULT .NAME\.CF) (-0.25)) 

(> (\CURRENT_FAULT .NAME\.CF) (-0.5)) 

) 

(3HYP0- Evaluate_Certainty_Factors) 

(2RHS= 

(Let (\CURRENT_FAULT.NAME\. CONFIDENCE) ("UNLIKELY")) 

) 

) 

(3RULE= RULE_025 QUAL I F I CAT ION_OF_CON F I DENCE UNKNOWN 

(8LHS= 

(> (\CURRENT_FAULT . NAME\. CF ) (-0.25)) 

(< (\CURRENT _FAULT .NAME\ . CF ) (0.25)) 

(3HYP0= Eva luate_Certainty_Fac tors) 

(3RHS= 

(Let (\CURRENT_FAULT.NAME\. CONFIDENCE) ("UNKNOWN")) 

) 

) 

(3RULE= RULE _024_QUAL I F I CAT I ON_OF _C0NF I DENCE_POSS I BLE 
(3LHS= 

( >= ( \CURRENT_F AULT . N AMEX . C F ) (0.25)) 

(< (\CURRENT FAULT. NAMEX.CF) (0.5)) 

) 

(3HYP0= Evaluate_Certainty_Factors) 

(3RHS= 

(Let (\CURRENT_FAULT.NAME\. CONFIDENCE) ("POSSIBLE")) 

) 

) 
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(3RULE= RULE 023_QUALIFICATION_OF_CONFIDENCE_LIKELY 

<aLHS= 

(>= (\CURREHT_FAULT.NAME\.CF) (0.5)) 

(< ( \CURREHT_F AULT . NAME\ . CF ) (0.75)) 

(3HYPO= Evaluate_Certainty_Factors) 

(3RHS- 

(Let (\CURRENT_FAULT.NAME\. CONFIDENCE) ("LIKELY") ) 

) 

) 


(3RULE= RULE_022 QUAL I F I CAT I 0N_0F _C0NF I PENCE PROBABLE 

(3LHS= A ^ 

( >= ( \CURRENT_FAULT . NAME\ . C F ) ( 0 . 75 ) ) 

(< (\CURRENT FAULT. NAME\.CF) (0.9)) 

) 

(3HYP0= Evaluate_Certainty_Factors) 

(3RH$= 

(Let (\CURRENT_FAULT.NAHE\. CONFIDENCE) ("PROBABLE")) 

) 

) 


(3RULE= RULE 021 QUALI FICATION_OF_CONFIDENCE ESTABLISHED 

(3LH$= 

(>= (\CURRENT_FAULT .NAHE\.CF ) (0.9)) 

) 

(3HYP0= Evatuate_Certainty_Factors) 

C SR HS~ 

(Let (\CURRENT_FAULT .NAME\. CONFIDENCE ) ("ESTABLISHED")) 

(Let (\CURRENT_FAULT.NAME\. VERIFIED) (TRUE)) 


) 


) 


(3RULE= RUL E_0 1 2 MOO E L_MA T R I X_SW ITCH 

(3LHS= 

(Is (MSWITCH. CONFIG) ("B")) 

( 3H Y P0= Mode l _Ma t r i x_S w i t ch_SubSy s t em) 

(3RHS= 

(CreateObject (HSWITCH_CH12) ( j SUBSYSTEMS J)) 
(CreateObject (MSWITCH_CH21 ) ( j SUBSYSTEMS j )) 

) 

) 

(3RULE= RULE 011_MOOEL_MATRIX_SWITCH 
(3LHS= 

(Is (MSWITCH. CONFIG) ("A")) 

(3HYP0= Model_Matrix_Swi tch_SubSystem) 

(3RHS= 

(CreateObject (MSWITCH_CH1 1 ) ( [SUBSYSTEMS )) 

(CreateOb j ect (MSWI TCH _CH22) ( j SUBSYSTEMS J ) ) 

) 

) 

(3RULE= RULE_902 — RETURN J.IST_OF_BAD_SENSORS_TOJoolBook 
(3LHS= 

(Yes ( TBK_Reques t . Bad_Sensors ) ) 

) 

(3HYP0= Return_BAD_Sensors ) 

(3RHS= 

(Let (C J BAD SENSORS J>.RTN_READ I NG) (TRUE)) 

(Strategy (3CACTI0NS0N=FALSE; )) 

< Reset ( C j BAD_SENSORS [ > . RTN_READ I NG ) ) 

(Strategy (3CACTI0N$0N=TRUE; )) 

(Execute ("BadSensorReadingsReturned") ) 

) 

) 
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(3RULE= rule_901_retrieve_sensor_parameters_from_sensor_database_and_return\ 

NOH I NAL_DATA JTO_T oo l Book 
(3LHS= 

(Yes (TBK Request. Nomina l _Sensor_Dat a) ) __ 

(Ret r i eve ( "SENSOR . nxp" ) (3TYPE=NXPDB; 3FWRD=FALSE ; aUNKNOWN=TRUE ;3PR0PS: 

NOMINAL , TOLERANCE , ZEROJ.EVEL ;3F I ELDS="NAME" , \ 

"NOMINAL", "TOLERANCE", »ZER0_LEVEL";3AT0MS=< | SENSORS |>;\ 

)) 

(3HYPO= Return_Nominal_Sensor_Data) 

(3RHS= 

(Do (<jSENSORS|>. NOMINAL) (< [SENSORS j>. NOMINAL)) 

) 

) 

(3RULE= RULE _003_QUAL I F I CAT I ON_OF_H I GH_SENSOR_LEVELS 
(3LHS= 

(> ( \CURRENT_SENSOR . NAME\ . ERROR ) (0)) 

(3HYP0= SensorJ.evel_Description.HIGH) 

(3RHS= 

(Let ( \CURRENT_SENSOR . NAME\. LEVEL ) ("HI GH" ) ) 

) 

) 

(3RULE= RULE_004 QUAL I F I CAT I ON_OF_LOW_SENSOR_LEVELS 

(3LHS= 

(< (\CURRENT_SENSOR .NAME\. ERROR) (0)) 

(3HYP0= Sensor_Levet_Descr ipt i on. LOW) 

(QRHS= 

(Let (\CURRENT_SENSOR . NAHE\ . LEVEL ) ("LOU 1 ')) 

) 

) 

(3RULE= RULE_005 QUAL I FICATION_OF_OK_SENSOR_LEVELS 

<SILH (<= ( ABS( \CURRENT_SENSOR . NAME\ . ERROR ) - \CURRENT_SENSOR . MAHE\. TOLERANCE ) 

(3HYP0= Sensor_Level_Description.OK) 

(3RHS= 

(Let (\CURRENT_SENSOR.NAME\. LEVEL) ("OK")) 

) 

) 


(SRULE= RULE_006 QUAL I F I CAT 10N_0F_ZER0_SENS0R_LEVELS 

(3LHS= 

(<= (\CURRENT_SENSOR.NAME\.DATA-\CURRENT_SENSOR.NAME\.ZERO_LEVEL) 


(3HYP0= Sensor_Level_Descript ion. ZERO) 

(3RHS= 

( Let ( \CURRENT_SENSOR . NAME\. LEVEL ) 


("ZERO")) 


) 


) 


( 0 )) 


(3RULE= RULE_001__QUAL I F I CAT I ON_OF_BAD_SEN$OR_READ I NGS 

<aLH (> ( ABS ( \CURRENT_SENSOR . NAME\ . ERROR ) - \CURRENT_SENSOR .NAME\ . TOLERANCE ) 

( 3HYP0= Sensor_Readi ng_Descr i pt i on . BAD ) 

(S)RHS~ 

(Let (\CURRENT_SENSOR.NAME\. READING) ("BAD")) 

(CreateObject (\CURRENT_SENSOR.NAME\) ( ]BAD_SENSORS | )) 

(Let (\CURRENT_SENSOR.NAME\. EVALUATED) (TRUE)) 

) 

) 


-NAME , \ 


( 0 )) 


( 0 )) 
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<3RULE= RULE_002 DUAL I F I CAT I ON_OF_GOOO_SENSOR_READ I NGS 

(SILH (<= (ABS(\CURRENT_SENSOR. NAME\. ERROR )-\CURRENT_SENSOR.NAME\. TOLERANCE) 

(3HYP0= Sensor_Readi ng_Desc r i pt i on . GOOD ) 

(3RHS= 

(Let (\CURRENT SENSOR. NAHE\. READING) ("GOOO")) 

(Let (\CURRENT~SENSOR.NAME\. EVALUATED) (TRUE)) 

) 


( 0 )) 


(3GL0BALS= 

aiNHVALUP=FALSE; 

3INHVALDOWN=TRUE; 

31 NHOB JUP=FALSE ; 

aiNHOBJDOWN=FALSE; 

aiNHCLASSUP=FALSE; 

aiNHCLASSDOUN=TRUE; 

3INHBREADTH=TRUE; 

31 NHPARENT= FALSE; 

aPUTRUE=TRUE; 

aPUFALSE=TRUE; 

aPWNOTKNOWN=TRUE; 

aEXHBWRD=TRUE; 

3PT GATE S=T RUE; 
3PFACT IONS=TRUE ; 
aSOURCESON=TRUE; 
aCACTIONSON=TRUE; 
aV0LLIST=PM_1 .DATA; 

) 



APPENDIX B 

FAULT DETECTION KNOWLEDGE BASE 


(3VERSI0N= 020) 


(30BJECT= A Fault_Has_BeenJ)etected 
(3PR0PER1 TeS= 

Value aTYPE=Boolean; 

) 

) 

(30BJECT= A Fault_Has_Not_Been_Detected 
CaPROPERTfES= 

Value 3TYPE=Boolean; 

) 

) 

OOBJECT= T ransponder_Func t i on i ng_P roper l y 

(3PR0PERTIES= 

Value aTYPE=Boolean; 

) 

) 

(3RULE= R1 
(3LHS= 

(Yes (TBK_Request .Detection)) 

(Is (< [SENSORS [>. READING) ("BAD")) 

(aHYPO= A Fault_Has_BeenJ)etected) 

(3RHS= 

(Execute ("FaultDetected") ) 

> 


(3RULE= R2 
(3LH$= 

(Yes (TBK__Request .Detect ion)) 

(Is (( | SENSORS |>. READING) ("GOOD")) 

(3HYP0= A_Faul t_H as_N o t_B een_D e t ec t ed ) 
(3RHS= 

(Execute (“NoFaul tDetected" ) ) 

) 
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APPENDIX C 

FAULT ISOLATION KNOWLEDGE BASE 


(3VERSI0N= 020) 

(30B JECT = Isolate_Fault_Symptoms 
(aPROPERTIES= 

Value QTYPE=Boolean; 

) 

) 

(3RULE= RULE04_I SOLAT ION_OF_FAULT_TO_FREQUENCY_CONPONENTS 
(3LHS= 

(Yes (TBKJtequest . Isolation)) 

(NotMember ((|BAD_SENSORS|>) (< jPWR_SENSORS|>)) 

(Is (<|BER_SENSORS|>.READIMG) ("BAD")) 

) 

(3HYP0= Isolate_Fault_Symptoms) 

) 


(3RULE= RULE01 I SOLAT ION_OF_FAULT_TO_SUBSYSTEM$ 

(3LHS= 

(Yes ( TBK_Reques t . I so l a t i on ) ) 

(Yes ( Mode l_Mat r i x_Sw i t ch Subsystems ) ) 

(Is (< JSUB SYSTEMS j>. READ INGJN) ("GOOO")) 

(Is (<! SUBSYSTEMS j >. READING OUT) ("BAD")) 


) 

( S)H YPO= I so l at e_F au l t_Sympt oms ) 

(3RHS= 

(Let ( < | SUBSYSTEMS | > . I SOL ATED ) 

(CreateObject (< [SUBSYSTEMS ]>) 


(TRUE)) 

( J I SOLATEDSU BS ystems i > > 


) 


) 
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APPENDIX D 

RECEIVER SUBSYSTEMS 
DIAGNOSTIC KNOWLEDGE BASES 


D.I CHANNEL 1 RECEIVER SUBSYSTEM 


(aVERSION= 

(aPROPERTY= 

(3PR0PERTY= 

(8PR0PERTY= 

(8PR0PERTY= 

OPR0PERTY= 

(8PR0PERTY= 

(aPROPERTY= 

(3PR0PERTY= 

(3PR0PERTY= 

(8PR0PERTY= 

<aPROPERTY= 

(8PR0PERTY= 

(3PR0PERTY= 

(3PROPERTY= 

<aPROPERTY= 

(3PR0PERTY= 

(3PR0PERTY= 

(8PR0PERTY= 

(8PR0PERTY= 

OPR0PERTY= 

OPR0PERTY= 

(aPROPERTY= 

(3PR0PERTY= 

OPR0PERTY= 

(8PR0PERTY= 

<aPROPERTY= 


020 ) 

CF aTYPE=Float; ) 

COMPONENT aTYPE=String; ) 
COMPONENT IN aTYPE=String; ) 
C0MP0NENT_0UT 3TYPE=String; ) 
CONFIDENCE 3TYPE=String; ) 
COUPLING aTYPE=Boolean; ) 

GAIN 3TYPE=Float; ) 

INF CAT aTYPE=Float; ) 

MB - 3TYPE=Float; ) 

MB ACCUM aTYPE=Float; ) 

MD - aTYPE=Float; ) 

MD ACCUM 3TYPE=Float; ) 

MODEL GAIN aTYPE=Float; ) 
MOOELJOWERJN 3TYPE=Float;) 
MODEL_POWER_OUT 3TYPE=Float; ) 

NAME aTYPE=String; ) 

NOMINAL GAIN 3TYPE=Float; ) 

NOM I NAL_POWER_OUT 3TYPE=Float; ) 

NOMINAL_SETTING 3TYPE=Float; ) 

NON I NAL_POUER_I N aTYPE=Float; ) 

POUERJN 3TYPE=Float;) 
POUER_LEVEL_I N aTYPE=String; ) 
POWER_LEVEL OUT aTYPE=String; ) 
POUER OUT 3TYPE=F loat; ) 

SETTING 3TYPE=Float; ) 

VERIFIED aTYPE=Boolean; ) 


(3CLASS= AMP_FAULTS 
(aPROPERTIES= 

CF 

COMPONENT 

CONFIDENCE 

INF_CAT 

MB 

MB_ACCUM 

MD _ 

MO_ACCUM 

NAME 

POUER_LEVEL_OUT 

VERIFIED 

) 

> 

<aCLASS= AMPLIFIERS 
(aPROPERTIES= 


COMPONENT IN 
COMPONENT OUT 
GAIN 

M00EL_GAIN 
MODEL POUER IN 
MODEL - POUER_OUT 
NAME _ 

NOMINAL GAIN 
NOMINAL_POUER OUT 
NON INAL POUER IN 
POUERJN 
POUER - LEVEL IN 
POUER "LEVEL OUT 
POUER OUT 

) 

) 

(3CLASS= ATTEN_F AULTS 

<aPROPERTIES= 

CF 

COMPONENT 

CONFIDENCE 

INFCAT 

MB 

MB_ACCUM 

MD 

MD ACCUM 
NAME 

POUERJEVEL OUT 
VERIFIED 

) 

) 

(3CLASS= ATTENUATORS 
OPROPERTIES= 
COMPONENT IN 
COMPONENT - OUT 
GAIN 

MODEL_GAIN 
MODEL POUER_IN 
MODEL'POUER OUT 
NAME " 

NOMINAL GAIN 
NOMINAL_POUER_OUT 
NOMINAL SETTING 
NONINAL - POUER_IN 
POUER IN 
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POWER_LEVEL_IN 

POWERJ.EVELJXJT 

POWERJDUT 

SETTING 

) 

) 

(3CLA$S= COMP COUPL I NG_FAUL TESTATES 
(3PR0PERTIES= 

CF 

COMPONENT 
CONFIDENCE 
INF CAT 
MB ~ 

MB_ACCUM 

MD~ 

MD_ACCUM 

NAME 

POWER LEVELJXJT 
VERIFIED 

) 

) 

(3CLASS= COMPONENTS 
(3SUBCLAS$ES= 

ATTENUATORS 
AMPLIFIERS 
RECEIVERS 
LOCAL OSCILATORS 

) 

(3PR0PERTIES= 

COMPONENT IN 
COMPONENT OUT 
GAIN 

MODEL_GAIN 
MOOEL POWER _IN 
model“power_out 
NAME “ 

NOMINAL GAIN 
NOMINAL POWER_OUT 
noninal“power_in 
POWER IN 
POWER_OUT 

> 

) 

(3CLASS= FAULT_STATES 
(3SUBCLASSES= 

ATTEN_FAULTS 
AMP_F AULTS 
RECEIVER_FAULTS 
LO FAULTS 

COMP COUPL ING_FAULT_STATES 

) 

(3PR0PERTIE$= 

CF 

COMPONENT 

CONFIDENCE 

INF_CAT 

MB 

MB_ACCUM 

MD 

MD_ACCUM 

NAME 

POWER_LEVEL_OUT 

VERIFIED 

> 

) 

(3CLASS= LEVEL_1_FAULT_STATES 
(3PR0PERT IES= 

VERIFIED 

) 


(3CLASS= LO__FAULTS 
(3PR0PERTIES= 

CF 

COMPONENT 

CONFIDENCE 

INF_CAT 

MB 

MB ACCUM 
MD~ 

MD ACCUM 
NAME 

POWER_LEVEL_OUT 

VERIFIED 

) 

) 

(3CLASS= LOCAL OSCILATORS 
(3PR0PERTIES=" 

COMPONENT_IN 

COMPONENTJXJT 

GAIN 

MODEL GAIN 
MODEL POWER IN 
MODEL _ POWER OUT 
NAME ” 

NOMINAL GAIN 
NOMINAL_POWER OUT 
NONINAL_POWER IN 
POWER IN 
POWER“LEVEL IN 

power“level_out 

powerIout 

) 

) 

(3CLA$S= RECEIVER_FAULTS 
(3PR0PERTIES= 

CF 

COMPONENT 
CONFIDENCE 
INF CAT 
MB ~ 

MB ACCUM 
MD~ 

MD ACCUM 
NAME 

POWER LEVEL OUT 
VERIFIED 

) 

) 

<3CLASS= RECEIVERS 
(3PR0PERTIES* 

COMPONENT_IN 
COMPONENT OUT 
GAIN 

MODEL_GAIN 
MODEL POWER IN 
MODEL“POWER OUT 
NAME ” 

NOMINAL GAIN 

NOMINAL>OWER_OUT 

NON I NAL_POWER_I N 

POWER JN 

POWER LEVEL IN 

POWERJ.EVELJXJT 

POWER_OUT 

) 

) 

<aCLA$S= UNCERTAINTY_OVERHEAD 
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(aSUBCLASSES= 

FAULT_STATES 

> 

(3PR0PERTIES= 

CF 

CONFIDENCE 

HB 

MB_ACCUM 

MD 

MD_ACCUM 

) 

) 


CaOB JECT= AMP_COUPL I NG 
(aCLASSES= 

AMP_FAULTS 

COMP_COUPL I NG_FAULT_STATE$ 

) 

(3PR0PERTIES= 

CF 

COMPONENT 
CONFIDENCE 
INF CAT 
MB ” 

MB_ACCUM 

MD 

MD ACCUM 
NAME 

POWERJ-EVEl OUT 
VERIFIED 

) 

) 

<aOBJECT= AMP GENERAL_FAI LURE 
(3CLASSES= 

AMP FAULTS 

) 

OPROPERTIES= 

CF 

COMPONENT 
CONFIDENCE 
INF CAT 
MB “ 

MB ACCUM 
MD" 

MD_ACCUM 

NAME 

POWER_LEVEL_OUT 

VERIFIED 

) 

) 

<30BJECT= ATTEN COUPLING 
OCLASSES= 

ATTEN_FAULTS 

COMP_COUPL I NG_FAULT_STATES 

) 

(aPROPERTIES= 

CF 

COMPONENT 

CONFIDENCE 

INF_CAT 

MB 

MB_ACCUM 

MD 

MO_ACCUM 

NAME 

POWER LEVELJXJT 
VERIFIED 

) 

) 


(aOBJECT= ATTEN GENERAL_FAILURE 
(3CLASSES= 

ATTEN FAULTS 

) 

<aPROPERTIES= 

CF 

COMPONENT 

CONFIDENCE 

INF_CAT 

MB 

MB_ACCUM 

MD 

MD ACCUM 
NAME 

POWER LEVEL OUT 
VERIFIED 

) 

) 

(30BJECT= ATTEN_SETTING 
<3CLASSES= 

ATTEN FAULTS 

) 

(aPROPERTIES= 

CF 

COMPONENT 

CONFIDENCE 

INF_CAT 

MB 

MB_ ACCUM 
MD 

MD ACCUM 
NAME 

POWER LEVEL OUT 
VERIFIED 

) 

) 

<30BJECT= CURRENT COMPONENT 
<aPROPERTIES= 

COUPLING 

NAME 

> 

) 

<30BJECT= CURRENT_FAULT 
(aPROPERTIES= 

NAME 

) 

) 

(30BJECT= CURRENT_$UBSYSTEM 
(3PR0PERTIES= 

POWERJ.EVEL OUT 

) 

) 

(aOBJECT= Develop_Diagnostic_Strategy 
(3PR0PERTIES= 

Value 3TYPE=Bootean; 

) 

) 

(30BJECT= Evaluate_Attenuator_Setting 
(aPROPERTIES= 

Value 3TYPE=Boolean; 

) 

) 

( 30B JECT= Eva l ua t e_Faul t_State_Conf i dence_Factors 
<aPROPERTIES= 

Value aTYPE=Boolean; 

) 



(©OBJECT 5 FN 
(©CLASSES 5 

FAULT_STATES 

) 

(©PROPERTIES 5 

CF 

COMPONENT 
CONFIDENCE 
INF CAT 
MB ” 

MB_ACCUM 

HD 

MD_ACCUM 

NAME 

POWER_LEVEL_OUT 

VERIFIED 

) 

) 

(©OBJECT 5 FO 
(©CLASSES 5 

FAULT STATES 

) 

(©PROPERTIES 5 

CF 

COMPONENT 

CONFIDENCE 

INF_CAT 

MB 

MB ACCOM 

md' 

MD_ACCUM 

NAME 

POWER LEVEL OUT 
VERIFIED 

) 

) 

(©OBJECT 5 FP 
(©CLASSES 5 

FAULT STATES 

> 

(©PROPERTIES 5 

CF 

COMPONENT 

CONFIDENCE 

INF_CAT 

MB 

MB_ACCUM 

HD 

MD_ACCUM 

NAME 

POWER_LEVEL_OUT 

VERIFIED 

) 

) 

(©OBJECT 5 FQ 
(©CLASSES 5 

FAULT_STATES 

) 

(©PROPERTIES 5 

CF 

COMPONENT 
CONFIDENCE 
I N F_CAT 
MB 

MB ACCUM 

md“ 

MD_ACCUM 

NAME 


POWER LEVEL OUT 
VERIFIED 

) 

) 

(©OBJECT 5 FR 
(©CLASSES 5 

FAULT_$TATES 

) 

(©PROPERTIES 5 

CF 

COMPONENT 

CONFIDENCE 

INF_CAT 

MB ACCUM 
MD“ 

MD ACCUM 
NAME 

POWER LEVEL OUT 
VERIFIED 

) 

) 

(©OBJECT 5 FS 
(©CLASSES 5 

FAULT STATES 

) 

(©PROPERTIES 5 

CF 

COMPONENT 
CONFIDENCE 
INF CAT 
MB “ 

MB ACCUM 
MD“ 

MD ACCUM 
NAME 

POWER LEVEL OUT 
VERIFIED 

) 

) 

(©OBJECT 5 FT 
(©CLASSES 5 

FAULT_STATES 

) 

(©PROPERTIES 5 

CF 

COMPONENT 
CONFIDENCE 
I NF_CAT 
MB 

MB_ ACCUM 
MD 

MD_ACCUM 

NAME 

POWER LEVEL_OUT 
VERIFIED 

) 

) 

(©OBJECT 5 FU 
(©CLASSES 5 

FAULT STATES 

) 

(©PROPERTIES 5 

CF 

COMPONENT 
CONFIDENCE 
INF CAT 
MB “ 

MB ACCUM 


MD 

HD ACCUM 
NAME 

POWER_LEVEL_OUT 

VERIFIED 

) 

) 

(©OBJECT 3 FV 
(©CLASSES 3 

FAULT_STATES 

) 

(©PROPERTIES 3 

CF 

COMPONENT 
CONFIDENCE 
INF CAT 
HB 

HB ACCUM 
MD~ 

MD ACCUM 
NAME 

POWER LEVEL_OUT 
VERIFIED 

) 

) 

(©OBJECT 3 FU 
(©CLASSES 3 

FAULT STATES 

) 

(©PROPERTIES 3 

CF 

COMPONENT 
CONFIDENCE 
INF CAT 
MB " 

MB ACCUM 
MD" 

MD ACCUM 
NAME 

POWER LEVEL_OUT 
VERIFIED 

) 

) 

(©OBJECT 3 FX 
(©CLASSES 3 

FAULT STATES 

) 

(©PROPERTIES 3 

CF 

COMPONENT 
CONFIDENCE 
INF CAT 
MB " 

MB_ACCUM 

MD 

MD_ACCUM 

NAME 

POWER_LEVEL_OUT 

VERIFIED 

) 

) 

(©OBJECT 3 FY 
(©CLASSES 3 

FAULT_STATES 

) 

(©PROPERTIES 3 

CF 

COMPONENT 

CONFIDENCE 


INF CAT 
M8 " 

MB ACCUM 
MD' 

MD ACCUM 
NAME 

POWER LEVELJXJT 
VERIFIED 

) 

) 

(©OBJECT 3 FZ 
(©CLASSES 3 

FAULT_STATES 

) 

(©PROPERTIES 3 

CF 

COMPONENT 

CONFIDENCE 

INF_CAT 

MB 

MB_ACCUM 

MD 

MD ACCUM 
NAME 

POWER_LEVEL OUT 
VERIFIED 

) 

) 

(©OBJECT 3 Initialize_Database 
(©PROPERTIES 3 

Value ©TYPE=Boolean; 

) 

) 

(©OBJECT 3 Level 1 Diagnostics 
(©PROPERTIES 3 * ~ 

Value ©TYPE=Boolean; 

) 

) 

(©OBJECT 3 LO COUPLING 
(©CLASSES 3 " 

COMP COUPLING_FAULT STATES 
LO FAULTS 

) 

(©PROPERTIES 3 

CF 

COMPONENT 
CONFIDENCE 
INF CAT 
MB ' 

MB_ACCUM 

MD 

MD_ACCUM 

NAME 

POWER_LEVEL_OUT 

VERIFIED 

) 

) 

(©OBJECT 3 LO GENERAL_FAI LURE 
(©CLASSES 3 " 

LO_FAULTS 

) 

(©PROPERTIES 3 

CF 

COMPONENT 
CONFIDENCE 
INF CAT 
MB 

MB ACCUM 
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MD 

MD_ACCUM 

NAME 

POWER_LEVEL_OUT 

VERIFIED 

) 

) 

<oK)BJECT= OPEN_GATE 
(3PR0PERT IES= 

Value 3TYPE=Boolean; 

) 

) 

(SOB JECT= RCVR_COUPL I NG 

(SICLASSES= 

COMP COUPL I NG_FAULT_STATES 
RECElVER^FAULTS 

) 

(3PR0PERT IES= 

CF 

COMPONENT 
CONFIDENCE 
INF CAT 
MB ' 

MB ACCUM 
MD' 

MD ACCUM 
NAME 

POWER LEVELJXJT 
VERIFIED 

) 

) 

(SK3B JECT= RCVR GENERAL_FAI LURE 
(a)CLASSES= 

RECEIVER FAULTS 

) 

(SPROPERTIES= 

CF 

COMPONENT 

CONFIDENCE 

INF_CAT 

MB 

MB ACCUM 
MD“ 

MD_ACCUM 

NAME 

POWER LEVEL_OUT 
VERIFIED 

) 

) 


(S)SLOT= ATTEN FAULTS. VERI F IED 
(a)SOURCES= 

(Do (SELF. NAME) (CURRENT_F AULT. NAME)) 

(Do (SELF. COMPONENT) 

(CURRENT COMPONENT. NAME)) 

1 Reset ( Eva l uate_At t enuat or_Set t i ng ) ) 

(Do (Evaluate_Attenuator_Setting) 

(Evaluate Attenuator_Setting)) 

) 

) 

(3SLOT= COMP_COUPL I NG_FAULT_STATES .VERIFIED 
(3SOURCES= 

(Do (SELF. NAME) ( CURRENT_FAULT . NAME ) ) 

(Do (SELF. COMPONENT) 

( CURRENT_COMPONENT . NAME ) ) 

(Reset (Test^ComponentCoupling)) 

(Do (Test_Component_Coupl ing) 

(Test Component Coupling)) 

f 

) 

(3SL0T= COMPONENTS. GAIN 
(3S0URCES= 

(Do (SELF.POWER_OUT-SELF .POWER_IN) 

(SELF. GAIN)) 

) 

OCACTIONS= 

(Do (SELF. POWERJN+SELF. GAIN) 
(SELF.POWER_OUT)) 

) 

) 

(3SLOT= COMPONENTS. MOOEL_GAIN 
(aSOURCES= 

(Do (SELF.NOMINAL_GAIN) (SELF.MODEL_GAIN)) 

) 

(3CACTI0NS= 

(Do (SELF. MODEL POUER_IN+SELF .MODEL_GAIN) 
( SELF. MOD E L_POWE R_OUT ) ) ' 

) 

) 

(3SL0T= COMPONENTS. MODE L_POWERJN 
(3S0URCES= 

(Do (\SELF. COMPONENT JN\. MODEL JOWERJXJT) 
(SELF .MOOEL POWER IN)) 

) 

(aCACTIONS= 

(Do (SELF. MOOEL POWERJN+SELF .MODEL_GAIN) 
( SELF. MOD EL_POWER OUT))' 

) 

) 


(30B JECT = Test_Component_Coupling 
(aPROPERT IES= 

Va l ue 3T YPE=Boo l ean; 

) 

) 

(3SL0T= AMP FAULTS. COMPONENT 
(3INITVAL= "AMPJ H ) 

(RunTimeValue C'AMPJ")) 

) 

) 

(3S LOT = ATTEN_FAULTS. COMPONENT 
(3INITVAL= "SAIZ") 

(3S0URCES= 

(RunTimeValue ("SAIZ 11 )) 

) 

) 


(3SLOT= COMPONENTS. MOOEL_POUER_OUT 
(3S0URCES= 

(Do (SELF.MODEL_POUER_IN+SELF.MOOEL_GAIN) 
(SELF.MOOEL_POUER OUT)) 

) 

(3CACTIONS= 

(Do (SELF. MOOEL POWER_OUT) 

(\SELF. COMPONENT OUT\.MOOEL_POWER_IN)) 

) 


(3SLOT= COMPONENTS. POWER_IN 
(3S0URCES- 

(Do (\SELF.COMPONENT_IN\.POWER_OUT) 
(SELF.POUER_IN)> 

) 

(3CACTI0NS= 

(Do (SELF. POWER_IN+SELF. GAIN) 
(SELF.POWER_OUT>) 
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) 

) 

<a$LOT= COMPONENTS. POWERJXJT 
(3S0URCES= 

(Do (SELF. POWERJN+SELF. GAIN) 
(SELF.POWER_OUT)) 

) 

(3CACTI0N$= 

(Do (SELF .POWER_OUT) 

(\SELF. COMPON E N T_OUT \ . POWE R_ I N ) ) 

) 


(3SLOT= FAULT_STATES.CF 
(3CACTI0NS= 

(Do (SELF. NAME ) ( CURRENT_FAULT . NAME ) ) 
(Reset 

(Evaluate Fault_State_Conf idence_Factors)) 

(Do 

(Evaluate Fault_State_Conf idence_Factors) 

(Evaluate“Fault~State_Conf idence_Factors)) 

) 

) 

(3$L0T= LO FAULTS. COMPONENT 
(3INITVAL= "RCVRLO") 

(RunT imeValue ("RCVRLO")) 

) 

) 

(3SL0T= RECEIVER FAULTS . COMPONENT 
(3INITVAL= ~'RCVR_1 11 ) 

(dSOURCES= 

(RunT imeValue ("RCVRJI") ) 

) 

) 

(3SL0T= SENSORS. LEVEL 
( 3$OURCES= 

(Do (SELF. NAME) ( CURRENT__SENSOR . NAME ) ) 
(Reset ( Sensor_Leve l_D esc r i pt i on . H I GH ) ) 

(Do (Sensor_Level_Descr i pt i on. HI GH ) 

(Sensor Level Descript ion. HIGH)) 

“ (Reset ( Sensor_Leve l _Descr i pt i on . ZERO ) ) 

(Do ( Sensor^Leve l_Desc r i pt i on .ZERO) 
(Sensor_Level Descrfpt ion. ZERO)) 

(Rese"t (Sensor _Levet_Descr i pt i on. LOW) ) 

(Do (Sensor_Level_Descr i pt i on. LOW) 
(Sensor_Level Descript ion. LOW) ) 

) 

) 

(3SL0T= UNCERTAINTY_OVERHEAD .MB 

3C0MMENTS="This the Measure of Belief (MB) slot 
for all objects utilizing the uncertainty 
overhead 11 ; 

(3INITVAL= 0.0) 

(3S0URCES= 

(RunT imeValue (0.0)) 

) 

(3CACTI0NS= 

(Do 

(SELF .MB_ACCUM+( 1 -SELF .MB_ACCUM)*SELF .MB) 
(SELF.MB_ACCUM) ) 

(Reset (SELF. MB)) 

) 

) 

OSL0T= UNCERTAINTY_OVERHEAD.MB_ACCUM 
(3INITVAL= 0.0) 

(3S0URCES= 


(RunTimeValue (0.0)) 

) 

<aCACTIONS= 

(Do (SELF.MB_ACCUM-$ELF .MD_ACCUM) 
(SELF.CF)) 

> 


OSLOT= UNCERTAINTY_OVERHEAD.MD 
(3INITVAL= 0.0) 

(3S0URCE$= 

(RunTimeValue (0.0)) 

) 

(aCACTIONS= 

(Do 

( SEL F . MD ACCUM+ ( 1 - SEL F . MO_ACCUM )*SE L F . MD ) 
(SELF.MDlACCUM)) 

(Reset (SELF.MD)) 

) 


(3SL0T= UNCERTAINTY_OVERHEAD.MD_ACCUM 
(3INITVAL= 0.0) 

(3SOURCES= 

(RunTimeValue (0.0)) 

) 

(3CACTI0NS= 

(Do (SELF. MB_ACCUM- SE L F . MD_ACCUM ) 
(SELF.CF)) 

) 


(3SLOT= AMP COUPLING. NAME 

( 3 I N I TVAL= "AMP_COUPL I NG" ) 

(3S0URCES= 

( RunT i meVa l ue ( "AMP_COUPL I NG" ) ) 

) 

) 

(3SL0T= AMP COUPL I NG . POWER_LEVEL__OUT 
(3INITVAL= "ZERO") 

(3S0URCES= 

(RunTimeValue ("ZERO")) 

) 

) 

(3SLOT= AMP_COUPLlNG.VERI FIED 

3 1 N FATOM=AMP_COUPL I N G . I N F_CAT ; 

) 

(3SL0T= AMP GENERAL_FA I LURE . NAME 

(31 N I TVAL= "AMP_GENERAL_FA I LURE" ) 

(3SOURCES= 

( RunT i meVa l ue ( "AMP_GENERAL_FA I LURE " ) ) 

) 

) 

(3SL0T= AMP_GENERAL FAILURE .POWERJ. EVE LJXJT 
(3INITVAL= "HIGH, LOW, ZERO") 

(3S0URCES= 

(RunTimeValue ("HIGH, LOW, ZERO")) 

) 

) 

(3SLOT= AMP GENERAL_FAILURE. VERIFIED 

31 N FAT 0M=AMP_GENERAL_F A I LURE . INF_CAT ; 

) 

(3SL0T= ATTEN_COUPL I NG . NAME 

(3 I N 1 T VAL= »ATTEN_COUPL I NG" ) 

(3SOURCES= 

( RunT i meVa l ue ( " ATTENJXAJPL I NG" ) ) 

) 
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(aSLOT= ATTEN_COUPLING.POWER_LEVEL_OUT 
(aiNITVAL= "ZERO") 
f^ntiurFSs 

(RunTimeValue ("ZERO")) 

) 

) 

<aSLOT= ATTEN_COUPLING. VERIFIED 

81NFAT0M=ATTEN_C0UPL I NG . I N F_CAT ; 


(aSLOT= ATTEN_GENERAL_FAI LURE . NAME 

OINITVAL= "ATTEN_GENERAL_FAILURE") 

(3$OURCES= 

(RunTimeValue (»ATTENJ5ENERAL_FAILURE»)) 

) 

) 

<aSLOT= ATTEN GENERAL_FAI LURE .POWER_LEVEL_OUT 
(3INITVAL= “HIGH, LOW, ZERO") 

OSOURCES* 

(RunTimeValue ("HIGH, LOW, ZERO")) 

) 

) 

OSLOT= ATTEN_GENERAL_FAILURE. VERIFIED 

aiMFATOH=ATTEN GENERAL_FAI LURE . INF_CAT ; 

) 

(3SL0T= ATTEN SETTING. NAME 

(3INITVAL= "ATTEN_SETTING") 

(aSOURCES= 

( RunT i meVa l ue ( "ATTEN_$ETT I NG" ) ) 

) 

) 

(3SL0T= ATTEN SETT I NG . POWER_LEVEL_OUT 
(3INITVAL= "HIGH, LOW, ZERO") 

(aSOURCES= 

(RunTimeValue ("HIGH, LOW, ZERO")) 

) 

> 

OSLOT= ATTEN_SETTING. VERIFIED 

aiNFATOM=ATTEN_SETTING. INF_CAT; 

) 

(3SL0T= CURRENT_COMPONENT. COUPLING 

aPROMPT="Check the coupling of 
aV(CURRENT_COMPONENT . NAME ) . Is the input or output 
connection loose ?"; 

aCOMMENTS="This slot will implemented by 
Too l Book" ; aWH Y=" I t is possible that 
aV(CURRENT_COMPONENT) is not coupled to the 
transponder correctly."; 

(a$OURCES= 

(AskQuestion 

( CURREN T_COMPON ENT . COUPL I NG) ( NOTKNOWN ) ) 

) 

) 

(aSLOT= CURRENT_SUBSYSTEM.POWER_LEVEL_OUT 
OINITVAL= "ZERO") 

(RunTimeValue ("ZERO")) 

) 

) 

(aSLOT= FN. VERIFIED 

aiNFATOM=FN. INF_CAT; 

) 


(aSLOT= FO. VERIFIED 

aiNFATOM=FO. INF_CAT; 

) 

OSLOT= FP. VERIFIED 

aiMFATOM=FP. IMF_CAT ; 

) 

(3SL0T= FQ. VERIFIED 

aiNFATOM=FQ. IMF_CAT ; 

) 

(aSLOT= FR. VERIFIED 

aiMFATOH=FR.IMF_CAT; 

) 

OSLOT= FS. VERIFIED 

aiNFATOM=FS.INF_CAT; 

) 

(aSLOT= FT. VERIFIED 

31 NFATOM=FT . I MF_CAT ; 

) 

(aSLOT= FU. VERIFIED 

ai N FATOM=FU . I N F_CAT ; 

) 

(aSLOT= FV. VERIFIED 

aiNFATOH=FV. IN F_CAT ; 

) 

(aSLOT= FW. VERIFIED 

aiNFATOH=FU. INF_CAT ; 

) 

(aSLOT= FX. VERIFIED 

aiMFATOM=FX.IMF_CAT; 

) 

OSLOT= FT. VERIFIED 

aiNFATOM=FY. INF_CAT ; 

) 

(aSLOT= FZ. VERIFIED 

8IMFAT0M=FZ.IHF_CAT; 

) 

(aSLOT= LO COUPLING. VERIFIED 

aiNFATOM=LO_COUPLING. INF_CAT; 

> 

(3SLOT= LO GENERAL FAILURE. VERIFIED 

aiNFATOM=LO GENERAL_F A I LURE . I N F_CAT ; 

) 

OSLOT= OPEN GATE 

aPROMPT="Something Is Wrong. The OPEN_GATE )S 
closed. Please enter TRUE to continue ..."; 

aCOMMENTS="The OPEN_GATE is a boolean slot 
which is always true. ";aWHY="The OPEN^GATE should 
always be TRUE. It is used as a condition of rules 
which must always fire to effect LHS actions."; 
(aiNITVAL= TRUE) 

(aSOURCES= 

(RunTimeValue (TRUE)) 

) 

) 

OSLOT= PM_1 .NAME 

(aiNITVAL= “PH_1 " ) 

(aSOURCES- 

(RunTimeValue ("PM_1")) 
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) 

) 

(3$L0T= PH 1. ZERO LEVEL 
(31NITVAL= -30.0) 

(3S0URCES= 

(RunTimeValue (-30.0)) 

) 

) 

(3SL0T= RCVR_COUPLING. VERIFIED 

31 NFATOM=RCVR _COUPL I NG . INF_CAT ; 

) 


RULE09 EVALUATE UNL I KELY_CONF IDENCE_FACTORS 

(8LHS- 

( <= ( \CURRENT_FAULT . NAME \.CF) (-0.5)) 

( > ( \CURRENT_FAULT . NAME\. C F ) (-0.75)) 

) 

(3HYPO= 

Eva l uate_Faul t S tate_Conf i dence_F actors ) 

(3RHS= 

(Let (\CURRENT_FAULT .NAME\. CONFIDENCE) 

("UNLIKELY”)) 

) 

) 


(3SL0T= RCVR_GENERAL_FAI LURE .VERIFIED 

aiNFATOM=RCVR_GENERAL_FAI LURE . INF_CAT ; 

) 

(3RULE= RULE01_DEVELOP_D I AGNOST I C_STRATEGY 

aC0MMENTS="This rule tests the signal power 
level symptoms of all fault states against the 
obserrved level. All matches are created in class 
of Level 1 Fault States. ";3WHY="A diagnostic 
strategy must be developed before Level 1 
Diagnostics can begi 
n. M ; 

(3LHS= 

(Retrieve ("CHIRCV.nxp") 

(3TYPE=NXPDB ; 3F I LL=ADD ; 3FWRD=FALSE ; S)UNKNOWN=TRUE ; \ 
3NAME= n \ Name ! 11 ; aPROPS= I N F_CAT ; 3F I ELDS=" I N F_CAT“ ; \ 

(Execute ("TestHultiValue") 

(3AT0MID=< J FAULT STATES | > . POWER_LEVEL_OUT ; \ 

aSTR I NG="3SUPER$ET , 3TEST =3V ( CURRENT__SUB$YSTEM . POWE 

R LEVEL OUT ) ,\ 

^ETURN=LEVEL_1 FAULT_STATES,3C0MP=STRING";\ 

)) 

(3HYP0= DevelopJ) i agnost i c_St rategy) 

<3RHS= 

(Do ( Level_1_Di agnost ics) 

(Level 1_0i agnostics)) 

) “ 

) 

(3RULE= 

RULE1 1 EVALUATE_REJECTED_CONFIDENCE_FACTOR$ 

(3LHS- 

(<= (\CURRENT_FAULT .NAME\.CF) (-0.9)) 

) 

(3HYP0= 

Evaluate Fault_$tate_Conf idence_Factors) 

(3RH$= 

(Let (\CURRENT_FAULT.NAME\. CONFIDENCE) 

(“REJECTED")) 

(Let (\CURRENT_FAULT.NAME\. VERIFIED) 

(FALSE)) 

) 

) 


RULE 10 EVALUATE IMPROBABLE_CONFIDENCE_FACTORS 

(3LHS= " _ 

(<= (\CURRENT_FAULT.NAME\.CF) (-0.75)) 

(> (\CURRENT FAULT. NAMEX.CF) (-0.9)) 

) 

(3HYP0= 

Evaluate_Faul t_State_Conf idence_Factors) 

(3RHS= 

(Let (\CURRENT_FAULT.NAME\. CONFIDENCE ) 
("IMPROBABLE")) 

) 


( 3RULE= RULE08 EVALUATE_CON F I DENCE_FACTORS 

(3LHS= 

(<= (\CURRENT FAULT. NAME\.CF) (-0.25)) 

( > ( \CURRENT ~F AULT . NAME\. C F ) (-0.5)) 

) 

(3HYP0= 

E va l ua t e_F au l t_St at e Conf idence_F actors) 

(3RHS= 

( Let ( \CURRENT_F AULT . NAME \ . CON F I DENCE )K 

")) 

) 

) 

(3RULE= RULE07__EVALUATE_UNKNOUN_CONFIDENCE_FACTORS 

(3LHS= „ 

(> (\CURRENT FAULT. NAME\.CF) (-0.25)) 

(< (\CURRENT FAULT. NAME\.CF) (0.25)) 

) 

(3HYP0= 

Evaluate_Faul t State__Conf idence_Factors) 

(3RHS= 

(Let ( \CURRENT_FAULT . NAME\. CONFIDENCE) 
("UNKNOWN")) 

) 

) 

(3RULE= RULE06 EVALUATE_CONF IDENCE _FACTORS 

(3LHS= 

(>= (\CURRENT FAULT. NAMEX.CF) (0.25)) 

(< (\CURRENT“FAULT.NAME\.CF) (0.5)) 

) 

(3HYP0= 

Evaluate Fault State Confidence^ actors) 

(3RHS= 

(Let ( \CURRENT_FAULT . NAME\ . CON F I DENCE )K 

")) 

) 

) 

(3RULE- 

RULE05 EVALUATE POSSIBLE _CONFIDENCE_FACTORS 

(3LHS= 

(>= (\CURRENT FAULT. NAME\.CF) (0.5)) 

(< (\CURRENT“FAULT.NAME\.CF) (0.75)) 

) 

(3HYPO= 

Evaluate_Fault_State_Conf i dene e_Fac tors) 

(3RHS= 

(Let ( \CURRENT_FAULT . NAME\. CON F I DENCE ) 

("POSSIBLE")) 

) 

) 

(3RULE= 

RULE04 EVALUATE PROBABLE_CONF IDENCE_FACTORS 

(3LHS= “ _ 

(>= (\CURRENT_FAULT.NAME\.CF) (0.75)) 

(< (\CURRENT_FAULT.NAME\.CF) (0.9)) 


) 


) 
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(3HYP0= 

Evaluate_Fault_$tate_Confidence_Factors) 

(3RHS= 

(Let (\CURRENT_FAULT .NAME\. CONFIDENCE) 
("PROBABLE 11 )) 

> 

) 


RULE03 EVALUATE_ESTABL I $HED_CONF I DENCE_FACTORS 

(3LH$= 

(>= (\CURRENT_FAULT.NAME\.CF) (0.9)) 

) 

(3HYPO= 

Evaluate_Fault State_Conf idence_Factors) 

(3RHS= 

(Let (\CURRENT_FAULT .NAME \. CONFIDENCE) 

("ESTABLISHED") ) 

(Let (\CURRENT FAULT .NAME\.VERI FIED) 

(TRUE)) 

) 

) 

(3RULE= RULE99 I N I T I AL I ZE_LEARN I NGJ)AT ABASE 

3C0MMENTS="This rule initializes the infefence 
categorys of all fault states to 1.0 in the 
CHlRCV.nxp dat abase" ;aWHY="At times in may be 
necessary to forget everything learned about the 
diagnostic strategy."; 

(3LHS= 

(Yes (OPEN_GATE)) 

) 

(3HYP0= Initial! zej) at abase) 

(3RHS= 

(Do (1.0) ( < | FAULT^STATES [>. IN F_CAT ) ) 

(Write ("CHlRCV.nxp") 

(3TYPE=NXPDB ; 3F I LL=NEW; 3UNKN0WN=TRUE ; 3NAME="< | F AUL 
T STATES 

3PR0PS= INF CAT ; 3 F I E LD S = » I N F_CAT » ; ) ) 

) 

) 

(3RULE= RULE 02 PURSUE LEVEL_1 J) I AGNOST I C_STRATEGY 

3C0MMENTS="This “rule effects Level 1 
Diagnostics by placing all fault states on the 
agenda" ;3UHY="Leve l 1 Diagnostics is the first step 
in the diagnostic process"; 

(3LHS= 

(Yes 

(< {LEVEL 1 FAULT STATESj>. VERIFIED)) 

) 

(3HYP0= L e ve l_1 _D i agnos tics) 

) 

(3RULE= RULE03 QUAL I F I CATION_OF_SENSOR_LEVEL 

(3LHS= 

(>= (\CURRENT_SENSOR .NAME\. ERROR) (0)) 

(3HYP0= Sensor_Leve IJJescr i pt i on . H I GH ) 

(3RHS= 

(Let ( \CURRENT_SENSOR . NAME\ . LEVEL ) 
("HIGH")) 

) 

) 

(3RULE= RULE 20 GENERIC_TEST_FOR_COMPONENT__COUPLING 

3C0MMENTS="This rule tests the signal power 
level symptoms of all fault states against the 
obserrved level. All matches are created in class 
of Level 1 Fault States.";3WHY="A diagnostic 
strategy must be developed before Level 1 
Diagnostics can begi 
n."; 


(3LHS= 

(Reset 

(Yes 

) 

(3HYPO= Test 
(3RHS- 

(Do (0.9 

) 


(CURRENT COMPONENT. COUPLING)) 
(CURRENT“COMPONENT. COUPLING)) 

_Component_Coup ling) 

) ( \CURRENT_FAUL T . NAHE\ . MB ) ) 
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D.2 CHANNEL 2 receiver subsystem 


OVERSI0N= 
OPROPERTY- 
OPR0PERTY= 
(3PR0PERTY= 
OPROPERT Y= 


020 ) 

DESCRIPTION aTYPE=String;) 
INF_CATEGORY 8TYPE=F loat; ) 
POWER_LEVEL OUT aTYPE=String; ) 
VERIFIED ~ S)TYPE=Boolean; ) 


OCLASS= FAULT_STATES 

OSUBCLASSES= 

HIGH_POWER FAULT_$TATES 
LOW_POWER__FAULT_STATES 
ZERO POWER_FAULT STATES 

) 

OPROPERT IES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(3CLA$S= HIGH POWER FAULT__STATES 

OPROPERT I ES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

> 

) 

(3CLASS= LOW POWER_FAULT_STATES 

(3PR0PERT IES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

<aCLASS= SUBSYSTEMS 

OPROPERT I ES= 

POWER LEVELJDUT 

) 

) 

OCLASS= ZERO_POWER_FAULT_STATES 

<aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 


(aOBJECT= Di agnose_H I GH_Power_Faul testates 
OPROPERT I ES= 

Value aTYPE=Boolean; 

) 

) 

(aOBJECT= D i agnose_LOW_Power_Faul t_$tates 

OPROPERT I ES= 

Value aTYPE=Boolean; 

) 

) 

(aOBJECT= Diagnose_ZERO_Power_Fault_States 


OPROPERT IES= 

Va l ue 8TYPE=Boo l ean; 

) 


(aOBJECT= I FPC Ampl i f i er_Coupl i ng_to_Systefn 
(aCLASSES- 

ZERO POWER FAULT STATES 

) 

OPROPERT I ES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(aOBJECT= I FPC_Ampl i f ier_Gerveral_Fai lure 
(aCLASSES= 

ZERO POWER FAULT_STATES 
high"power“fault STATES 
LOW POWER FAULTjTATES 

) 

OPROPERT I ES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

OOBJECT= IFPCJVnplif ierJ>ower_Supply_Fai lure 

OCLAS$ES= 

ZERO POWER_FAULT STATES 

) 

OPROPERT I ES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

OOB JECT= I FPC At tenuator_Coupl i ng_to_System 

OCLASSE$= 

ZERO POWER FAULT_STATES 

) 

OPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(aOBJECT= IFPCJtttenuator_General_Fai lure 
(aCLASSES= 

ZERO POWER_FAULT_STATES 
high“power FAULT_STATES 
LOW POWER_FAULT STATES 

) 

OPROPERT I ES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 
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(SOBJECT- I FPC_Attenuator_Set t i ng_I s_I ncor rec t 
OCLASSES= 

HIGHTOWER FAULT STATES 
LOW_POWER FAULTjTATES 
ZERO_POWER_FAUL TESTATES 

) 

<aPROPERTIES= 

DESCRIPTION 

lNF_CATEGORY 

VERIFIED 

) 

) 

(^OBJECT- 

Local Osci l lator_Frequency_$etting_Is_Incorrect 

/ari assps= 

ZERO_POWER_FAULT_STATES 
LOW POWER_FAULT_STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

> 

) 

(30BJECT= Local Osci l lator_General_Fai lure 
(aCLASSES= 

LOW POWER FAULT_STATES 
ZERO POWER FAULT_STATES 

) 

(aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

OOBJECT* 

Local Oscillator Out of_Phase_Lock Alarm 

(aCLASSE$= 

ZERO POWER_FAULT_STATES 
LOW POWER_FAULT_STATES 

) 

(aPROPERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(30BJECT= 

Local Osci l lator_Out_of_Phase_Lock Test 

(aCLASSES= 

ZERO_POWER_FAULT_STATES 
LOW_POWER_FAULT_ST ATES 

) 

(aPROPERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 


OOBJECT= Local _Osci l lator_Power_Supply_Fai lure 
(3CLASSES= 

ZERO_POWER FAULT STATES 
LOW POWE R_F AU L T_ST ATES 

) 

<aPROPERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 


) 

) 

(30BJECT= 

Local Oscillator Signal_Power _Level_IsJ_OW 
(S)CLASSES= 

ZERO POWER FAULT_STATES 
LOW POWER FAULT_STATES 

) 

^PROPERTIES* 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(aOBJECT= Receiver_Unit_Coupling_to_System 
(aCLASSES= 

ZERO POWER FAULT STATES 

) 

(3PR0PERTIES* 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

O0BJECT= Receiver Uni t_General_Fai lure 
(aCLASSES= 

HIGH POWER FAULT STATES 
LOW POWER FAULT STATES 
ZERO POWER FAULT_STATES 

) 

(3PR0PERTIES- 
DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

<aOBJECT= 

Receiver Unit Primary_Power_Supply_Fai lure 
(3CLASSES* 

ZERO POWER FAULT_STATES 

) 

(aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(aOBJECT= 

Receiver Unit_SecondaryJ>ower_Supply_Fai lure 
<aCLASSES= 

ZERO POWER FAULT_STATES 

) 

(aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(aOBJECT= Undef ined_General_Fai lure 
<aCLASSE$= 

H I GH_POWER_FAULT_STATES 
LOW_POWER FAULT_STATES 
ZERO_POWER FAULT_STATES 

) 

<aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
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VERIFIED 


) 

OOBJECT- 

ZZ_Outstanding_Fault_States_for_Channel_2_Recei ver 

System 

“ /ari A^^FSs 

H I GH POWER FAULT STATES 
LOW POWER_FAULT_STATE$ 
ZERO_POWER_FAULT_STATES 

) 

OPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(3SLOT= IFPC_Ampl if ier_Coupl ing_to_System.VERI FI ED 

aiNFATOH=I FPC_Ampl i f i er_Coupl i ng_to_System. I NF _CAT 
EGORY; 

) 

OSLOT= IFPC_Ampl if ier_General_Fai Lure.VERI FI ED 

3INFAT0M=I FPC_Ampl i f i er_General _Fai lure. I NF _CATEGO 
RY; 

) 

(aSLOT= 

I FPC_Ampl i f ier_Power_Supply_Fai Lure.VERI FIED 

a I N FATOH= I FPC Amp l i f i er_Power_Supp ly_Fai lure. INF_C 
ATEGORY; 

) 

<aSLOT= IFPC_Attenuator_Coupling_to_System.VERIFIED 

aiNFATOH=I FPC Attenuator_Coupl ing_to_System. INF_CA 
TEGORY; 

) 

<aSLOT= I FPC_Attenuator_General_Fai Lure.VERI FI ED 

aiNFATOH=I FPC Attenuator_General_Fai lure. INF_CATEG 
ORY; 

) 

(aSLOT= 

I FPC_At tenuat or_Set t i ng_I s_I ncor rect . VER I F I ED 

aiNFATOM=I FPC_Attenuator_Sett ing_Is_Incorrect . INF_ 

CATEGORY; 

) 

OSLOT= 

Local_Osci l Lator Frequency_Setting_IsJncorrect .VE 
RIFIED 

aiNFATOH=Local_Osci l lator_Frequency_Sett ing_Is_I nc 
orrect . INF_CATEGORY; 

) 

(aSLOT= Local_Osci l lator_General_Fai Lure.VERI FIED 

aiNFATOH=Local - Osci l tator_General_Fai lure. INF_CATE 
GORY; 

) 


casLOT= 

Local_Osci l lator_Out_of_Phase_Lock Alarm. VERI FIED 


aiNFATOM=local Osci l Lator_Out_of_Phase_Lock Alarm 

.INF CATEGORY; - 

) 


Local Osci l lator_Out_of_Phase_Lock Test .VERIFIED 

aiNFATOM=Local Osci Hat orJ)ut_of _Phase_Lock Test. 

INF CATEGORY; ” 

) 

casLOT= 

Loca l_Osc i l l ator_Power_Supp ly_F a i l ure .VERIFIED 

ai NFATOM'Loca l_Osci l lator_Power_Supply_Fai lure. INF 
CATEGORY; 

T 


OSLOT= 

Local Osci l lator_Signal JPowerJ-eveMsJ-OU. VERI FIED 
aiNFATOH=Local Osci l lator_Si gnal _PowerJ.evel_Is_LO 

w.inf_category7 

) 

( as LOT = Rece i ver JJni t_Coupl i ng_to_Syst em. VER I F I ED 

aiNFATOM=Receiver Uni t_Coupl ing_to_$ystem. INF_CATE 
GORY; 

) 

(3SLOT= Receiver_Unit_General_Fai Lure. VERIFIED 

aiNFATOM=Receiver Uni t_General_Fai lure. IN FCAT EGOR 

Y; 

) 

OSLOT= 

ReceiverJUni t_Primary_Power_Supply_Fai lure. VERI FIED 

aiNFATOM=Receiver UnitJ>rimary_Power_Supply_Fai lur 
e. INF CATEGORY; 

) 


Receiver Unit Secondary_Power_Suppl y_Fa i Lure. VERI F 
I ED 


QINFATOM=ReceiverJJni t_Secondary_Power_Supply_Fai l 

ure. INF_CATEGORY; 

) 

OSLOT= Undef ined_General_Fai Lure.VERI FIED 

a I N FATOM=Undef i nedJSenera l_Fa i l ure . I N F_CATEGORY ; 

) 

(3SL0T= 

ZZ_Out standing Fault_States_for_Channel_2_Receiver 
^System. VERI FIED 

aiNFATOM=ZZ_Outstar»ding_Fault_States_for_Channel_2 

_Receiver_System. INF CATEGOX 

RY; 


(ORULE= R1 
(3LHS= 

(Is ( < J SUBSYSTEMS j > . POWER_LEVEL_OUT ) *H1I» 
(Yes 

(< [HIGH POWER_FAULT STATES |>. VERI FIED)) 

) 


) 


(3HYP0= Diagnose_HIGH_Power_Fault_States) 


<3RULE= R2 
(3LHS= 

(Is (<! SUBSYSTEMS j > . POWER_LEVEL_OUT ) 

(“LOW")) 

(Yes 

( < | LOWJ>OWER_FAULT_$TATE$ J > . VER I F I ED ) ) 

(3HYP0= DiagnoseJ_OW_Power_Fault_$tates) 

) 

(3RULE= R3 
(3LHS= 

(Is ( < | SUBSYSTEMS \ > . POWER J. EVE L_OUT ) 

("ZERO”)) 

(Yes 

( < | ZERO_POUER_FAULT_STATES J > . VER I F I ED ) ) 

(3HYP0= D i agnose_ZERO_Power_Faul t_States) 


) 


APPENDIX E 

MATRIX SWITCH SUBSYSTEM 
DIAGNOSTIC KNOWLEDGE BASE 


<3VERSI0N= 

(3PR0PERTY= 

(3PR0PERTY= 

(3PR0PERTY= 

<3PR0PERTY= 


020 ) 

DESCRIPTION aTYPE=$tring; ) 

INF CATEGORY 3TYPE=F loat; ) 
P0WER_LEVEL_0UT aTYPE=String; ) 
VERIFIED " 3T YPE=Boo t ean; ) 


(aCLASS= FAULT_STATES 

<aSUBCLASSES= 

HIGH POWER_FAUL TESTATES 
L0U_P0WER FAULT_STATES 
ZERO POWER FAULT_$TATES 

) 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(3CLAS$= HIGH POWER_FAULT_STATES 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 


OOBJECT= Diagnose HIGH_Power_Fault_States 
(3PR0PERTIES= 

Va l ue aTYPE=Boo L ean; 

) 

) 

(SlOBJECT= D i agnose_LOW_Power_Faul t_States 
(aPROPERTIES= 

Value 3TYPE=Boolean; 

) 

) 

(30BJECT~ D i agnose_ZERO_Power_Faul testates 
(aPROPERTIES= 

Value 3TYPE=Boolean; 

) 

) 

(30BJECT= I FPC_Ampl i f i er_Coupl i ng_to_System 
(aCLASSES= 

ZERO_POWER_FAULT_STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 


(3CLASS= LOW_POWER_FAUL TESTATES 

(3PR0PERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

<aCLASS= SUBSYSTEMS 

(3PR0PERT IES= 

POWER_LEVEL_OUT 

) 

) 


( 30B JECT= I FPCJUnpl i f i er_Genera l_F a i l ure 

/an 

ZERO POWER FAULT STATES 
HlGH>OWERlFAULT STATES 
LOW POWER FAULT_$TATES 

) 

(aPROPERTIES= 

DESCRIPTION 

1NF_CATEG0RY 

VERIFIED 

) 

) 


(3CLASS= ZERO_POWER__FAUL TESTATES 

(3PR0PERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 


(30BJECT= IFPC_Amplif ier\_Power_Supply_Fai lure 
/an a^sfs= 

ZERO POWER_FAULT_STATES 

) 

(aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 
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> 

) 

(SOBJECT- I FPC_Attenuator_Coupl ing_to_System 
(3CLASSES= 

ZERO_POWER_FAULT_STATES 

) 

(S)PROPERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

> 

) 

(SOBJECT= IFPC_Attenuator_General_Fai lure 
(3CLASSES= 

ZERO_POWER_FAUL TESTATES 
H I GH_POWER_FAULT_STATES 
L OW_P OWE R_ FAULT STATES 

) 

(<DPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(5>OBJECT= I FPC_At tenuat or_Set t i ng_I s_Incorrect 
/ari a^^fs= 

HIGH POWER FAULT_STATE$ 

LOW POWER FAULT_STATES 
ZERO POWER FAULT^STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= 

Matrix_Switch_Conf iguration_Is_Incorrect 

(SiCLASSES= 

ZERO POWER_FAULT_S TATES 

) 

(3PR0PERT IES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

> 

) 

(dOBJECT- Hatrix_Switch_General_Fai lure 
<aCLASSES= 

ZERO_POWER_FAULT_ST ATES 
H I GH~POWER_FAULT STATES 
LOW_POWER_FAULT STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

( SOB J ECT= Ma t r i x_S w i t ch_Path_Set t i ng_I s_I ncorrec t 

ran accccs 

ZERO_POWER_FAUL TESTATES 

) 

(3PROPERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 


) 

) 

(SOBJECT= Undefined_General_Failure 
(3CLASSES= 

HIGH POWER FAULT_STATES 
LOW POWER_FAULT_STATES 
ZERO POWER FAULT_STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(S)OBJECT= 

ZZ_Outstanding_Fault_$tates_for_Matrix_Swi tch_Syst 

em 

( SC LASSES- 

HIGH POWER_FAULT STATES 
LOW_POWER FAULT STATES 
ZERO_POWER FAULT_STATES 

) 

(SPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(SSLOT= I FPC_Amp 1 1 f i er _Coupl i ng^to^System.VER I F I ED 

SINFATOM=IFPC_Ampl i f ier_Coupl i ng_to__System. INF _CAT 
EGORY; 

) 

(SSLOT= IFPC_Amplif ier_General_Fai lure.VERI FI ED 
3INFATOM=IFPC_Ampl if ier_General_Fai lure. INF_CATEGO 

RT; 

) 

(SSLOT= 

IFPC_Amplif ier_Power_Supply_Fai lure.VERI FI ED 

SINFATOH-IFPC Ampl i f ierJ>ower_Supply_Fai ture.INF_C 
AT EGORY; 

) 

(SSL0T= I FPCJUtenuator^Coipl i ng_to_System. VER I F I ED 

aiNFATOM=I FPC_Attenuator _Coupl ing_to_System. INFJIA 
TEGORY; 

) 

<SSLOT= IFPC_Attenuator_General_Fai lure.VERI FI ED 

31 N FATOM= I FPC_At tenuat or_Genera l_F a i l ure . I N FCATEG 
ORY; 

) 


I FPC_Attenuator_Setting_Is_Incorrect. VERIFIED 

aiNFATOH- 1 FPC At tenuat or_Set t i ng_I s_I ncor rec t . I N F_ 
CATEGORY; 

) 

(3SLOT= Undef ined_General_Fai lure.VERI FI ED 

SINFATOM=Undef ined_General_Fai lure. INFLATE GORY; 

) 



(3SL0T= 

2Z_0ut standing Fault_States_for_Matrix_Swi tch_Syst 
emTvERIFIED 

31 NFATOM=ZZJXit standi ng_Fautt_States_for_Matrix_Sw 

i tch_System. I NF_CATEGORY ; 

) 

(3RULE= R1 
<3LH$= 

(Is (< j SUBSYSTEMS | > .POWERJ_EVEL_OUT ) 
(••HIGH 11 )) 

(Yes 

( < | H l GH_POWE R_FAULT_$TATES [ > . VER I F I ED ) ) 

(3HYP0= Diagnose_HIGH_Power_FauL t_States) 

) 

(3RULE- R2 
(3LHS= 

(Is ( < j SUBSYSTEMS j > . POWER _LEVEL JDUT ) 

("LOW")) 

(Yes 

( < | LOW_POUER_FAULT_S TATES J > . VER I F I ED ) ) 

(3HYP0= Diagnose_LOU_Power_Fault_States) 

) 

(3RULE= R3 
(3LH$= 

(Is < < | SUBSYSTEMS J > . POWER J.EVELJXJT ) 
("ZERO")) 

(Yes 

(< } ZERO_POWER_FAULT_STATES | > . VER I F I ED ) ) 

(3HYP0= Diagnose_ZERO_Power_Faul testates) 

) 


APPENDIX F 

UP-CONVERTER SUBSYSTEMS 
DIAGNOSTIC KNOWLEDGE BASES 


F.l CHANNEL 1 UP-CONVERTER SUBSYSTEM 


<aVERSION= 

OPR0PERTY= 

<3PR0PERTY= 

(3PR0PERTY= 

(3PR0PERTY= 


020 ) 

DESCRIPTION aTYPE=Str ing; ) 

INF CATEGORY QTYPE=F loat ; ) 
POWERJ.EVELJXIT 3TYPE=String; ) 
VERIFIED 3T YPE=Boo l ean; ) 


OCLASS= FAULT_STATES 
(aSUBCLASSES= 

HIGH POWER FAULT STATES 
LOW POWER FAULT_STATES 
ZERO POWER_FAULT_STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

<aCLASS= H I GH_POUER_FAULT_STATES 

OPROPERTIES* 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

OCLASS= LOW_POWER_FAULT_$TATES 

(3PROPERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

OCLASS= SUBSYSTEMS 

<3PROPERTIES= 

POWER LEVEL_OUT 

) 

) 

<aCLASS= ZE RO_POWE R_F AUL T_ST AT E S 

<aPROPERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 


) 

) 


<aOBJECT= Diagnose HIGH Power _Fault_States 
(aPROPERTIES= 

Va L ue 3T YPE=Boo l ean; 

) 

) 

(aOBJECT= Diagnose LOW_Power_Fault_States 
<aPROPERTIES= 

Value aTYPE=Boolean; 

) 

) 

(aOBJECT= Diagnose ZERO_Power_Fault_States 
(aPROPERTIES= 

Value 3TYPE=Boolean; 

) 

) 

( SOB J E CT = HPAD I PC_A 1 1 enua t o r_Coup l i ng_t o_Sys t em 

(3CLASSES= 

ZERO POWER_FAULT STATES 

) 

(aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(aOBJECT= HPAD I PC Attenuator_General_Fai lure 
OCLASSES= 

ZERO POWER FAULT_STATES 
high“power!fault_states 
LOW POWER FAULT_STATES 

) 

(QPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(QOBJECT= HPAD I PC_At tenuator__Sett i ng_I s_I ncorrect 
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/ an iccpc = 

HIGH_POWER_FAULT_STATES 
LOW_POWER_FAULT_STATES 
ZERO_POWER_FAULT_S TATES 

) 

(3PR0PERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(30BJECT= HPAI PC_Ampl i f i er_Coupl i ng_to_System 
OCLASSES= 

ZERO_POWER__FAULT_STATES 

) 

OPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= HPAIPC^Ampl if ier_General_Fai lure 
/an accpcs 

2ER0 POWER_FAULT STATES 
HIGH~POWER_FAULT STATES 
LOW POWER_F AUL T_ST AT E S 

) 

OPROPERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(SK)BJECT= HPAIPC_Ampl if i er_Power_Supply_Fai lure 
/ari a5SFS= 

ZERO POWER FAULT_STATES 

) 

(3PR0PERT I ES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(o)OBJECT= HPAIPC_Attenuator_Coupl ing_to_System 
OCLASSES= 

ZERO POWER_FAULT_ST ATES 

) 

(aPROPERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

<aOBJECT= HPAIPC_Attenuator_General_Fai lure 
/an 

ZERO_POWER FAULT_STATES 
high“power!fault_states 

LOW POWER_FAULT_STATES 

) 

(3PR0PERT IES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

OOBJECT= HPAIPC_Attenuator_$ett ing_Is_Incorrect 
(aCLASSES= 


H I GH_POWER_FAULT STATES 
LOW POWER_FAULT_$TATES 
ZERO POWER FAULT STATES 

) 

(3PRQPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(aOBJECT= 

Local Oscillator Frequency_Sett ing_Is_Incorrect 
<aCLASSES= 

ZERO_POWER FAULT_STATES 
LOW POWER_FAULT_STATES 

) 

<3PR0PERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(30BJECT= Local Osci l lator_General__Fai lure 
OCLAS$ES= 

LOW_POWER_FAULT STATES 
ZERO_POWER FAULT_STATES 

) 

(aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT* 

Local Oscillator Out_of_Phase_Lock Alarm 

<aCLASSES= 

ZERO POWER FAULT STATES 
LOW POWER FAULT STATES 

) 

^PROPERTIES* 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(30BJECT = 

Local Osci llator_Out_of_PhaseJ.ock Test 

(3CLASSES* 

ZERO_POWER FAULT_$TATES 
LOW_POWER FAULT_STATES 

) 

OPROPERTIES- 
DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 


(30BJECT* Local Osci l lator_Power_$upply_Fai lure 
<aCLASSES= 

ZERO POWER_FAULT_STATES 
LOW POWER_FAULT_STATES 

) 

(3PR0PERTIES* 

DESCRIPTION 

INFJTATEGORY 

VERIFIED 

) 
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<30BJECT= 

Loca l_0sc i l L ator Si gna t_Power_Leve l _I s_L0W 
(aCLASSES= 

ZERO_POWER_FAULT_STATES 

LOW_POWER_FAULT_STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(SKDBJECT= Hi xer_Um t_Coupl i ng_to_System 

(S)CLASSES= 

ZERO_POWER_FAULT_STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(QOBJECT= Mixer Unit General_Fai lure 
(S)CLA$SES= 

HIGH_POWER_FAULT_STATES 
LOW_POWER_F AU L T_ST AT E S 
ZERO POWE R_ FAULT_S TATES 

) 

<3PR0PERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(30BJECT= Undef ined_General_Fai lure 
<aCLAS$ES= 

HIGH POWER FAULT STATES 
LOW_POWER FAULT STATES 
ZERO POWER_FAULT STATES 

) 

OPR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

<30BJECT= 

Z Z_0u t s t and i ng_ Fault _States_fo r _C hannel_1_Upc on v e r 

telesystem 
“/an & ccr c= 

HI GH_POWER_FAULT STATES 
LOW_POUER_FAULT_S TATES 
ZERO_POWER_FAULT_STATES 

> 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(3SL0T= 

HPAD I PC_A 1 1 enua t or _C oup l i ng_t o_Sy s t em . VE R I F I ED 

ai NFATOM=HPAD I PC_Attenuator_Coupl i ng_to_System. INF 
CATEGORY; 

) 

(3SL0T= HPADIPC_Attenuator_General_Fai lure.VERI FIED 


3INFAT0M=HPADIPC_Attenuator_General_Fai lure. INF_CA 
TEGORY; 

) 

<3SL0T= 

HPAD I PC Jit t enuat or_Set t i ng_ I s_I ncor rec t . VER I F I ED 

aiNFATOM=HPAD I PC At t enuator_$et t i ngj s_I ncorrect . I 
NF CATEGORY; 

) 

(aSLOT= 

HPA I PC Jimp l i f i er_Coupl i ng_to_Syst em. VER I F I ED 

31 NFATOM=HPAI PC_Ampl i f i er_Coupl i ng_to_System. I N F_C 
ATEGORY; 

) 

( aSLOT= HPA I PC_Ampl i f i er_Gener a l_F a i l ur e . VER I F I ED 

aiNFATOM=HPAIPC_Amplif i er_General_Fai lure. INFLATE 
GORY; 

) 

(aSL0T= 

HPA I PC Jimp l i f i er _Power_Suppl y_Fa i lure.VERI FIED 

aiNFATOM=HPAIPC_Ampl if ier_Power_Supply_Fai lure. INF 
CATEGORY; 

) 

(3SL0T= 

HPAI PC Jlttenuator_Coupl i ng_to_Sys tern. VER I F I ED 

3 1 N FAT0M=HPA I PC Jl 1 1 enua tor_Coup l i ng_t o_Sys t em . I N F_ 
CATEGORY; 

) 

(aSLOT= HPAlPCJlttenuatorJieneralJ^ilure.VERIFIED 

aiNFATOM=HPAIPC_AttenuatorJ5eneral_Fai lure. INF_CAT 
EGORY; 

) 

<aSLOT= 

HPA I PC_Attenuator_Set t i ng_I s J ncor rec t . VER I F I ED 

a I N FATOM=HPA I PC At tenuat or_Sett i ng_I s J ncor rect . I N 
F CATEGORY; 

r 

<3$L0T= 

Loca l Osc i 1 1 ator_F requency_Set t i ng_I s_I ncor rec t . VE 
RIFIED 

a INFATOH=Loca l Osc i 1 1 ator_F requency_Set t i ng_I s_I nc 
orrect . I NF_CATEGORY ; 

) 

OSLOT= Local_0sci l lator_General_Fai lure.VERI FIED 

aiNFATOH=Local_Osci l lator_General_Fai lure. INF_CATE 
GORY; 

) 


Local_0sci l lator_Out_of_Phase_Lock Alarm. VERI FIED 

aiNFATOH=Local Osci l lator_Out_of_Phase_Lock Alarm 

,INF_CATEGORY;~ 

) 
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Local_Osci l lator_Out_of_Phase_Lock Test - VER I FI ED 

SI NFATOM=Loca l _Osc i l lator_Out_of_Phase_Lock T est . 

INF_CATEGORY; " 

) 

(SSLOT= 

Local _Osci l l at or_Power_Supply_Fai lure. VERIFIED 

SINFATOM=Local_Osci l lator_Power_Supply_Fai lure. I NF 
CATEGORY; 

7 

(SSLOT= 

Local_Osci l lator_Signal_Power_Level_Is_LOW.VERI FIED 
SINFATOM=Local_Osci l lator_Signal_PowerJ_eveMs_LO 

U. INF CATEGORY! 

) 

( SSLOT = M i xe rjin i t _C oup l i ng_ t o_Sys t em . VE R I F I ED 
SINFATOM=Mixer_Um t_Coupl ing_to_System. INF_CATEGOR 

Y; 

) 

(SSLOT= MixerJJnit_General_Fai lure.VERI FIED 

SINFATOM=Mixer_Uni t_General__Fai lure. INF_CATEGORY; 

) 

( SSLOT = Undef ined_General_Fai lure.VERI FIED 

SIN FATOM=Undef i ned_Genera l_F a i l ure . I N F_CATEGORY ; 

) 

(SSLOT= 

2Z_Outstanding_Fault_States_for__Channel__1_Upconver 

ter System.VERIFIE\ 

D 

S I N FATOM=ZZ_Out s t and i ng_F au l t_S t a t es_f o r_Channe l _1 
Upconverter System. IN F_CAT\ 

EGORY; 

) 

(SRULE= R1 
(SLHS= 

(Is ( < | SUBSYSTEMS | > . POWER_LEVEL_OUT ) 

("HIGH 11 ) ) 

(Yes 

< < |HIGH_POWER_FAULT_STATES j > . VER l F I ED ) ) 

(SHYPO= Diagnoses I GH_Power_Fault_States) 

) 

(SRULE= R2 
(SLHS= 

(IS (< J SUBSYSTEMS j > . POWER_LEVE L_OUT ) 

('‘LOW' 1 )) 

(Yes 

( < J LOW_POWER_FAUL TESTATES | > . VER I F I ED ) ) 

(SHYPO= D i agnose_LOW_Powe r_F au l t_S t a t es ) 

) 

(SRULE= R3 
(SLHS= 

(Is ( < | SUBSYSTEMS j > . POWER_LE VEL_OUT ) 

( "ZERO'* )) 

(Yes ( < | ZERO_PGWER_FAULT_STATES J> . VERI FIE)) ) 

) 


(SHYPO= D i agnose_ZERO_Power_Fau l t_$tates) 
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F.2 CHANNEL 2 UPCONVERTER SUBSYSTEM 


(AVERSION* 

(3PR0PERTY= 

<3PR0PERTY= 

(3PR0PERTY= 

(3PR0PERTY= 


020) 

DESCRIPTION S)TYPE=$tnng; ) 
INF_CATEGORY 3TYPE=F loat; ) 
P0WER_LEVEL_0UT 3TYPE=String; ) 
VERIFIED “ 3TYPE=Boolean; ) 


<aCLASS= FAULT_STATE$ 
(aSUBCLA$SES= 

H I GH_POWER_FAULT_ST ATES 
LOW POWER_FAULT_STATES 
ZERO_POWER_FAULT_STATES 

) 

(QPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(3CLAS$= HIGH POWER_FAULT_STATES 

^PROPERTIES* 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(3CLA$$= LOW_POWER FAULT_STATES 

^PROPERTIES* 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(S)CLA$S= SUBSYSTEMS 

(3PR0PERT IES= 

POWER_LEVEL_OUT 

) 

) 

(3CLASS* ZERO_POWER_FAULT_STATES 

(aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 


(30BJECT* Diagnose_H I GH_Power_Faul testates 
(3PR0PERTIES= 

Value 3TYPE=Boolean; 

) 

) 

<aOBJECT= D i agnose_LOU_Power_Faul t_States 

(3PR0PERTIES* 

Value 3TYPE=Boolean; 

) 

) 

(308JECT* D i agnose_ZERO_Power_Faul t_States 

(3PR0PERT IES= 

Value QTYPE=Boolean; 


) 

) 

(30BJECT* HPADIPC Attenuator j:ouplir>g_to_$yste<n 
<3CLASSES= 

ZERO POWER_FAULT_STATES 

) 

<aPROPERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

<aOBJECT= HPADIPC Attenuator JSenera l _Fai lure 
<3CLASSES= 

ZERO POWER FAULT STATES 
H I GH”POWER”FAULT_S TATES 
LOW POWE R_F AUL T_S T ATES 

) 

(3PROPERTIES* 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

<30BJECT= HPADIPC Attenuator_$etting_Is_Incorrect 
(3CLASSES* 

HIGH_POWER FAULT STATES 
LOW POWER FAULT_STATES 
ZERO POWER FAULT_STATES 

) 

^PROPERTIES* 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(S)OBJECT= HPAIPC Arnplif ier_Coupling_to_System 
(aCLASSES= 

ZERO POWER FAULT_STATES 

) 

(3PR0PERTIES* 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

OOBJECT= HPAlPC_Ampl if ier_General_Fai lure 
<aCLAS$ES= 

ZERO_POWER FAULT_STATES 
HIGH POWER FAULT STATES 
LOW POWER_FAULT_STATES 

) 

<aPROPERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(aOB JECT* HPAI PCJVnpl i f i er _Power_$upply_Fai lure 

<aCLASSES= 
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ZERO POWER_FAUL TESTATES 

) 

(3PR0PERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

> 

) 

OOBJECT= HPAIPC_Attenuator_Coupl ing_to_System 

/art 

ZE RO_POWE R_F AU L T_ST AT E S 

) 

(SPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(SKDBJECT= H PA I PC_A 1 1 enua t o r_G ene r a l _F a i lure 

(QCLASSES= 

ZERO POWER_FAULT STATES 
high“power'fault_states 
LOW POWER FAULT STATES 

) 

<aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= HPAIPC_Attenuator_Set t i ng_I s_I ncor rect 

OCLASSES= 

HIGH_POWER FAULT_$TATES 
LOW POWER _?AULT_STATES 
ZERO POWER_FAULT_STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

<aOBJECT= 

Local Osc i 1 1 a t or_F r equency_Set t i ng_I s_I ncorr ec t 
(3CLASSES= 

ZERO POWER_FAULT_STATES 
LOW_POUER_FAUL TESTATES 

) 

(SPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(aOBJECT= Local _Osci l lator_General_Fai lure 

OCLASSES= 

LOW_POWER_FAULT_STATES 
ZERO_POWER_FAULT_S TATES 

) 

(3PR0PERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(5K)BJECT= LocalJDsci l lator_Ojt_of_Phase_Lock__Alann 
(aCLASSES= 


ZERO_POWER_FAULT STATES 
LOW POWER_FAULT_STATES 

) 

(aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(aOBJECT= 

Local Oscillator Out_of_Phase_Lock Test 

(aCLASSES= 

ZERO POWER FAULT STATES 
LOW_POWE R_?AU L T STATES 

) 

^PROPERTIES* 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= Local Osci l lator_Power_Supply_Fai lure 
(3CLASSES= 

ZERO POWER FAULT_STATES 
LOW POWER FAULT STATES 

) 

^PROPERTIES* 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

<S)OBJECT= 

Local_Osci l lator Signal Power_Level_Is_LOW 
<aCLAS$ES= 

ZERO_POUER FAULT_STATES 
LOW_POWER FAULT_STATE$ 

) 

^PROPERTIES* 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(OOBJECT* Mixer Uni t_Coupl ing_to_Systetn 
<aCLASSES= 

ZERO_POWER_FAUL TESTATES 

) 

(aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

OOBJECT* Mixer_UnitJjeneral_Fai lure 
<aCLASSE$= 

HIGH_POWER_FAULT_STATES 
LOW_POWER FAULT STATES 
ZERO POWER FAULl_STATES 

) 

^PROPERTIES* 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 


(30BJECT* Undef ined_General_Fai lure 
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OCLASSES= 

HIGH POWE R_F AU L T_S TATES 
LOW_POWER_F AUL T_ST AT E S 
ZERO_POWER_FAULT_STATES 

) 

(3PR0PERT IES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(30BJECT* 

ZZ_Outstanding_Fault_States_for_Channel_2_Upconver 

ter_System 

“/an icccc= 

H I GH_POUER_FAULT_STATES 
LOU POUER_FAULT_STATES 
ZERO_POWER_FAULT STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

<aSLOT= 

HPADIPC_Attenuator_Coupling_to_System. VERIFIED 

31 NFATOM-HPAD I PC Attenuator_Coupl ing_to_System. INF 
_CATEGORY; 

) 

<aSLOT= HPADlPC_Attenuator_General_Fai lure. VERIFIED 

3INFAT0M=HPADIPC_Attenuator_General_Fai lure.INF_CA 
TEGORY; 

) 

(aSLOT= 

HPAD I PC_Attenuator_Sett i ng J s_l ncor rect .VERIFIED 

3INFAT0M-HPAD I PC At tenua tor_Set t i ng_I s_I ncorrect . I 
NF CATEGORY; 

) “ 

(3SL0T= 

HPA I PC_Amp t i f i er_Coup l i ng_t o_Sy s t em .VERIFIED 

31 NFATOM=HPA I PC_Airpl i f i er_Coupt i ng_to_Syst em. I N F_C 
ATEGORY; 

) 

(3SL0T= HPAIPC_Ampl i f i er_General_Fai lure.VERI FIED 

aiNFATOM=HPAIPC Ampl i f i er_General_Fai lure. INF_CATE 
GORY; 

) 

(aSLOT= 

HPAIPC_Ampl i f ier_Power_Supply_Fai lure.VERI FIED 

aiNFATOH=HPAIPC_Ampl i f i er_Power_Supply_Fai lure. INF 
— CATEGORY; 

) 

(aSLOT= 

HPAIPC_Attenuator_Coupl ing_to_$ystem.VERI FIED 

aiNFATOH=HPAIPC_Attenuator_Coupl ing_to_System. INF_ 
CATEGORY; 

) 


OSL0T= HPAIPC_Attenuator_General_Fai lure. VERIFIED 

aiNFATOM=HPAIPC_Attenuator_General_Fai lure.INF_CAT 
EGORY; 

) 

OSLOT= 

HPAIPC_Attenuator_Setting_Is_I ncor rect. VERIFIED 
3INFAT0M=HPAIPC_Attenuator_Setting_Is_Incorrect. IN 

F CATEGORY; 

r 

(3SL0T= 

Local Oscillator Frequency_Setting_Is_I ncor rect .VE 
RIF I ED 

aiNFATOH=Local Osci Uator_Frequency_$ett ing_I s_Inc 
orrect. INF CATEGORY; 

) 

(3SL0T= Local_0sci l lator_General_Fai lure.VERI FIED 

aiNFATOM=Local_Osci l lator_General_Fai lure. INFLATE 
GORY; 

) 

(3SL0T= 

Loca l _0sc i 1 l at or_Out_of _Phase_Lock A l arm. VER I F I ED 

aiNFATOM= Local Osci l lator_Out_of_Phase_Lock Alarm 

.INF CATEGORY;" 

) 

(aSLOT= 

Loca l_Osc i 1 1 at or_Out_of_Phase J.ock T es t .VER I F I ED 

3INFAT0M=Local Osci Hat or_Out_of_Phase_Lock Test. 

INF_CATEGORY; " 

) 

OSLOT= 

Local_Osci l lator_Power_Supply_Fai lure.VERI FIED 

aiNFATOH=Local Osci l lator_Power_$upply_Fai lure. INF 
_CAT EGORY; 

) 


Local Oscillator_Signal_Power_Level_IsJ.OW.VERI FIED 

aiNFATOH=Local_Osci l lator_Signal_Power_Level_Is_LO 
W.1NF_CATEG0RY; 

) 

( as LOT = M i xe r_Un i t_C oup l i ng_ t o_Sy s t em . VE R I F I E D 

aiNFATOM=Mixer Unit Coupl ing_to_System. INF_CATEGOR 
Y; 

) 

(3SLOT= Mixer_Unit_General_Fai lure.VERI FIED 

3INFAT0M=Mixer_Unit_General_Fai lure. INF_CATEGORY; 

) 

OSLOT= Undefined_General_Fai lure.VERI FIED 

3INFATOM=Undef ined_General_Fai lure. INF_CATEGORY; 

) 
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ZZ_0utstaixIing_Fault_$tates_for_Channel_2JJpconver 

ter System.VERI F I E\ 

D 

3IMFAT0H=ZZ_0utstanding - Faul t_States_for_Charvnel_2 
_Upconverter_$ystem. INF_CAT\ 

EGORY; 

) 

(3RULE= R1 
(3LHS= 

(Is ( < 1 SUBSYSTEMS | > . POWER_LE VE LJXJT ) 
("HIGH”)) 

(Yes 

( < j H I GH_POWER_FAULT_STATES J > . VER I F I ED ) ) 

(3HYPO= D i agnose_H I GH_Power_F au l testates ) 

) 

(3RULE- R2 
(3LHS= 

(Is ( < | SUBS YSTEMS J > . POWER_LEVEL_OUT ) 

("LOW")) 

(Yes 

(< | LOW_POWER_FAULT_STATES j > . VER I F I ED ) ) 

(3HYP0= D i agnose_LOW_Power_Faui t_States) 

) 

(3RULE= R3 
(3LHS= 

(IS (< j SUBSYSTEMS !> . POWE R_LEVE L_OUT ) 
("ZERO")) 

(Yes 

( < | ZERO_POWER_FAULT_STATES j > . VER I F I ED ) ) 

(3HYP0= Diagnose_ZERO_Power_Fault_States) 

) 


APPENDIX G 

HIGH POWER AMPLIFIER SUBSYSTEMS 
DIAGNOSTIC KNOWLEDGE BASES 

G.l CHANNEL 1 AMPLIFIER SUBSYSTEM 


(3VERSI0N= 

<3PR0PERTY= 

<3PR0PERTY= 

^PROPERTY* 

(3PR0PERTY= 


020 ) 

DESCRIPTION 3TYPE=String; ) 

INF CATEGORY 3TYPE=F loat ; ) 
POWER_L EVE LJDUT 3TYPE=String; ) 
VERIFIED aTYPE=Boolean; ) 


OCLASS= FAULT_STATES 
(3SUBCLASSE$= 

HIGH_POWER_FAULT STATES 
LOW POWER FAULT STATES 
ZERO POWER FAULT_STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(aCLASS= HIGH POWE R_ F AU L T_S T AT E S 
(aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

<aCLASS= LOW POWE R_F AUL T_ST AT E S 
(3PR0PERT IES= 

DESCRIPTION 
INFLATE GORY 
VERIFIED 

) 

) 

(aCLA$S= SUBSYSTEMS 

(aPROPERTIES= 

POWER LEVEL_OUT 

) 

) 

<aCLASS= ZERO_POWER_FAULT_S TATES 

(aPROPERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 


) 

) 


(30BJECT= Diagnose HIGH_Power_Faul t_States 
(3PROPERTIES= 

Value aTYPE=Boolean; 

) 

) 

(30BJECT= Diagnose_LOW_Power_Fault_States 
(aPROPERTIES= 

Va l ue 3T YPE=Boo l ean ; 

) 

) 

(30BJECT= D i agnose ZEROJ>ower_Faul t_States 
(aPROPERTIES= 

Value aTYPE=Boolean; 

) 

) 

(aOBJECT= HPADIPC_Attenuator_Coupling_to_System 
(3CLASSES= 

ZERO_POWER_FAULT STATES 

) 

^PROPERTIES* 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

OOBJECT= HPADlPC_Attenuator_General_Fai lure 
(3CLASSES* 

ZERO POWER_FAULT_ST ATES 
HIGH'POWER FAULT_STATES 
LOW POWER FAULT STATES 

) 

(aPROPERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

( 30BJECT= HPAD I PC_A 1 1 enuator_Set t i ng_I s_I ncorrect 
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fan a<;qf§= 

H I GH_POWE R_F AU L T_ST AT E S 

LOW_POWER_FAULT_STATES 

ZERO_POWER_FAULT_STATES 

) 

(3PR0PERT IES= 

DESCRIPTION 

INF_CATEG0RY 

VERIFIED 

) 

) 

(S)OBJECT= HPAIPC_Ampl i f i er_Coupl i ng_to_System 
fan 

ZERO_POWER_FAULT_STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= HPAIPCJVnplif ier_General _Fai Lure 

OCLASSES* 

ZERO POWER FAULT_STATE$ 

HIGH~>0WER’"FAULT STATES 
LOW POWER_FAULT STATES 

) 

<3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= HPAIPC_Ampl if ier_Power_Supply_Fai lure 
(3CLA$SES= 

ZERO POWER FAULT STATES 

> 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= HPAIPC_Attenuator_Coupl ing_to_System 
(3CLASSES= 

ZERO_POWER_FAULT_STATES 

) 

CaPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= HPAIPCJ\ttenuator_General_Fai lure 
(3CLASSES= 

ZERO__POWER_FAUL TESTATES 
H I GH_POWER_FAULT_STATES 
L OW_P OWE R_ FAULT STATES 

) 

<3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

<aOBJECT= HPAIPC_Attenuator_Setting_Is_Incorrect 
OCLASSES= 


HIGH POWER FAULT STATES 
LOW POWER FAULT_STATE$ 

ZERO POWER FAULT STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= 

Local Oscillator Frequency_Sett ing_Is_Incorrect 
(aCLASSES= 

ZERO_POWER_FAULT STATES 
LOW POWER FAULT STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

OOBJECT= Local_Osci llator_General_Fai lure 
<3CLASSES= 

LOW_POWER_FAULT_STATES 

ZERO_POWER_FAULT_STATES 

) 

<aPROPERTIE$= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= 

Local_Osci llator_Out of_Phase_Lock Alarm 

(aCLASSES= 

ZERO_POWER_FAULT STATES 
LOW POWER_FAULT_STATE$ 

) 

<aPROPERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(30BJECT* 

Local_Osci l lator Out of Phase_Lock Test 

<3CLASSES= 

ZERO POWER_FAULT_$TATES 
LOW_POWER FAULT STATES 

) 

(aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= Local_Oscillator_Power_Supply_Fai lure 
(3CLASSES= 

ZERO_POWER_FAULT_STATES 
LOW POWER_FAULT STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 
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<30BJECT= 

Local_Osci l lator_Signal_PowerJ.evel_Is_LOW 
fan ” 

ZERO POWER_F AU L T_S TATES 
LOW POWER_FAUL TESTATES 

) 

(3PR0PERT IES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(30BJECT= Mixer_Uni t _Coupl ing_to_System 

fan a^fs= 

ZERO_POWER_FAULT_STATES 

) 

(3PR0PERT IES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= MixerJJni tJ5eneral_Fai lure 
(^CLASSES- 

HIGH_POWER_FAULT_STATES 
LOW POWER FAULT_STATE$ 

ZERO POUER_FAULT STATES 

> 

<3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= Undef ined_General_Fai lure 
(3CLASSES= 

HIGH POWER FAULT STATES 
LOWjPOWER FAUL TESTATES 
ZERO POWER_FAULT_STATES 

) 

(3PR0PERT IES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= 

ZZ_Outstanding_Fault_States_for_Channel_1 JJpconver 

ter System 
“<3CLASSES= 

H I GHJ > OWER_FAUL TESTATES 
LOW POWER_FAULT_STATES 
ZERO_POWER_FAULT STATES 

) 

(^PROPERTIES 51 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(3SL0T= 

HPADIPC_Attenuator_Coupling_to_System. VERIFIED 

3INFAT0M=HPADIPC_Attenuator_Coupl i ng_to_$ystem. INF 
_CATEGORY; 

) 

(3SLOT= HPADIPC_Attenuator_General_Fai lure. VERIFIED 


3INFATOM=HPADIPC_AttenuatorJ3eneral_Fai lure. INF_CA 
TEGORY; 

) 

<3SL0T= 

HP AD I PC_Attenuator_Set t i ng J s_ I ncor rec t . VER I F I ED 

3 1 N FATOM=HPAD I PC At t enuat or_Set t i ng J s_I ncor rect . I 
NF_CATEGORY; 

) 

(3SL0T= 

HPA I PC_Arrpl i f i er_Coup l i ng_t o_Syst em. VER I F I ED 

31 NFATOM=HPAI PC Amp l i f i er _Coupl i ng_to_$ystem. I N F_C 
AT EGOR Y; 

) 

( 3SL0T= HPA I PC_Ampl i f i er_Genera l _F a i l ure .VERIFIED 

3INFAT0M=HPAIPCJVnplif ierJ5eneral_Fai lure. INF_CATE 
GORY; 

) 

(3SL0T= 

HPA I PC Jimp l i f i er _Power_Suppl y_Fa i l ure . VER I F I ED 

3 1 N FATOM=HPA I PC Ampl l f i er J>ower_Supp ly_Fai lure. INF 
_CATEGORY; 

) 

(3SL0T= 

HPAIPC_Attenuator_Coupling_to_$ystem. VERIFIED 

3INFAT0M=HPAIPC_Attenuator_Coupl ing_to_System. INF_ 
CATEGORY; 

) 

(3SL0T= HPAIPC_Attenuator_General_Fai lure.VERI FIED 

3INFATOM=HPAlPCJlttenuator_General_Fai lure. INF__CAT 
EGORY; 

) 

(3SLOT= 

HPA I PC Jit t enuat or_Set t i ng J s_I ncor rect . VER I F I ED 

3INFAT0M=HPAIPC Attenuator_Setting_Is_Incorrect. IN 
F CATEGORY; 

r 

<3SL0T= 

Local Osc i 1 1 at or_F requency_Set t i ng_I s J ncor rect . VE 
RIFIED 

3 1 N FATOM=Loca l_Osc ilia tor_F requency_Set t i ng _I s_I nc 
or rect . I NF — CATEGORY ; 

) 

(3SL0T= Local _Osc i l lator_General_Fai lure.VERI FIED 

3INFAT0H=Local Osci l lator_General_Fai lure. INF_CATE 
GORY; 

) 


Local J3sc i l lator_Out_of_Phase_Lock A l arm. VER I F I ED 

3INFAT0M=Local Osci l latorJXit_of_PhaseJ.ock Alarm 

.INF CATEGORY;" 

) 
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OSL0T= 

Local_Osci l lator_Out_of_Phase_Lock Test .VERIFIED 

aiNFATOM=Local_Osci l lator_Out_of J>hase_Lock Test. 

IMF_CATEGORY; 

) 

(3SL0T= 

Local_Osci L lator_Power_Supply_Fai lure.VERI FI ED 

aiNFATOH=Local_Osci l lator J>ower_Supply_Fai lure. INF 
CATEGORY; 

) 

(3SLOT= 

Local Osci Uator_Signal_Power_level_IsJ.OW.VERI FIED 

aiNFATOM=Local_Osci l lator_Signal J>ower_Level _Is_LO 
U. INF CATEGORY; 

) 

(3SL0T= Hi xer JJni t_Coupl i ng_to_System. VER I F I ED 
aiNFATOH=Mixer Uni t_Coupl ing_to_System. INF_CATEGOR 

t; 

) 

(3SL0T= Mixer_Unit_General_Fai lure.VERI FIED 

aiNFATOH=Mixer Uni t_General_Fai lure. INF_CATEGORY; 

) 

(aSLOT= Undef i ned_Genera l_Fai l ure . VER I F I ED 

aiNFATOM=Undef ined_General_Fai lure. INF_CATEGORY; 

) 

(aSLOT= 

ZZ_0utstanding_Fault_States_for_Channel_1 JJpconver 

ter System. VERT f I E\ 

D 

aiNFATOM=ZZ_Outstanding_Faul t_States_for_Channel_1 
Upconverter_System. INF_CAT\ 

EGORY; 

) 

(QRULE= R1 
<aLHS= 

(Is ( < | SUBSYSTEMS | > . POWER J_EVEL_OUT ) 
("HIGH")) 

(Yes 

(< [HIGH POWER FAULT_STATES|>. VERIFIED)) 

) 

(3HYP0= Diagnose HI GH_Power_FauL t_States) 

) 

(3RULE- R2 
(3LHS= 

(Is ( < | SUBSYSTEMS | > . POWER_LE VE LJXJT ) 

(“LOW 11 )) 

(Yes 

( < j LOW_POUER_FAULT_STATES j > . VER I F I ED ) ) 

) “ 

(3HYP0= Diagnose_LOW_Power_Faul t_States) 

) 

(3RULE= R3 
(3LHS= 

(Is ( < | SUBSYSTEMS J > . POWER_LEVEL_OUT ) 
("ZERO")) 

(Yes ( < | ZERO_POWERJAULTjSTATES [ > . VER I F I ED) ) 

) 


(aHYPO= Diagnose_ZERO_Power_Fault_States) 
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G.2 CHANNEL 2 AMPLIFIER SUBSYSTEM 


AVERSION* 020) 

(3PR0PERTY= DESCRIPTION 3TYPE=String; ) 
(SPROPERTY* INF_CATEGORY 3TYPE=Float; ) 
OPR0PERTY= P0WER_LEVEL_0UT 3TYPE=String; ) 
OPR0PERTY= VERIFIED aTYPE=Boolean; ) 


(3CLASS= FAULT_STATE$ 
(aSUBCLASSES= 

H I GH_P0WER _FAULT_STATES 
LOW POWER_FAULT_STATES 
ZER0_P0WER_FAULT_ST ATES 

) 

(3PROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

<3CLASS= H I GH_POWER_FAULT_STATES 

<aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(aCLASS= LOW POWER_FAULT_STATES 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

<3CLASS= SUBSYSTEMS 

(aPROPERTIES= 

POWER LEVEL_OUT 

) 

) 

(aCLA$$= ZERO_POWER_FAULT_$TATES 

(3PR0PERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 


(30BJECT= Diagnose HIGH_Power_Faul t_States 
(3PR0PERT I ES= 

Value 3TYPE=Boolean; 

) 

) 

OOBJECT= Diagnose LOW_Power_Fault_States 
(3PR0PERTIES= 

Value 3TYPE=Boolean; 

) 

) 

(30BJECT= D i agnose_ZERO_Power_Faul t_States 

(3PR0PERTIES= 

Value 3TYPE=Boolean; 


> 

) 

OOBJECT= HPADIPC Attenuator_Coupl ing_to_System 
<3CLASSES= 

ZERO_POWER_FAULT STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(aOBJECT= HPADIPC Attenuator General_Fai lure 
<aCLASSES= 

ZERO POWER_FAULT STATES 
HIGH~POWER FAULT STATES 
LOW POWER FAULT STATES 

) 

<aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= HPADIPC Attenuator_Setting_Is_Incorrect 
(3CLASSES- 

HIGH POWER FAULT STATES 
LOW POWER FAULT STATES 
ZERO POWER_F AUL T_$T ATES 

) 

(aPROPERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

<a08JECT= HPAIPC Amp l i f i er_Coupl i ng_to_System 
<aCLASSE$= 

ZERO POWER FAULT_STATES 

) 

^PROPERTIES* 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= HPAIPC_Ampl i f i er_General_Fai lure 
(aCLASSES* 

ZERO POWER FAULT_STATES 

H I gh“power~fault_states 

LOW POWER_FAULT STATES 

) 

(3PROPERTIES* 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(30BJECT* HPAIPC Amplffier_Power_Supply_Failure 
(3CLASSES* 
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ZERO__POWER_FAUL TESTATES 

) 

(3PR0PERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

(30BJECT= HPA I PC_At t enuat or_Coup l i ng_to_System 

fan asses= 

ZERO_POWER_FAULT_STATES 

> 

(3PR0PERT IES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(SOBJECT= HPAIPC_Attenuator_General_Fai lure 
<3CLASSES= 

ZERO POWER_FAULT_STATES 
HIGH"POWER_FAULT STATES 
LOW_POWER FAULT STATES 

) 

OPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

<aOBJECT= HPA I PC Attenuator_Setting_Is_Incorrect 
(aCLASSES= 

HIGH_POWER_FAULT STATES 
L OW_P OWE R_ FAULT STATES 
ZERO_POWER FAULT_STATES 

) 

(aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

> 

) 

<aOBJECT= 

Local Osci l lator_Frequency_Sett ing_Is_Incorrect 
fan 

ZERO POWER_FAULT_STATES 
LOW POWER_FAULT_S TATES 

) 

OPROPERT IES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= Local Osci Uator_General_Fai lure 
(3CLASSES= 

LOW_POWE R_FAUL T_ST AT E S 
ZERO_POWER_FAULT_STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

CaOBJECT= 

Local Osci l lator_Out_of_Phase_Lock Alarm 


(3CLASSES= 

ZERO_POWER_FAULT_S TATES 
LOW_ POWER FAULT_$TATES 

) 

(3PR0PERTIES= 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

) 

) 

OOBJECT= 

Local_Osci llator Out_of_PhaseJ_ock Test 

(aCLASSES= 

ZERO POWER FAULT_STATES 
LOW POWER FAULT_STATES 

) 

(aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(aOBJECT= Local Osci l latorJ^ower^Supply^Fai lure 
<3CLASSES= 

ZERO POWER_FAULT_STATES 
LOW_POWER_FAULT_STATES 

) 

(aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(5)OBJECT= 

Local_Osci llator Signal_Power_Level_IsJ-OW 
(aCLASSE$= 

ZERO POWER FAULT STATES 
LOW_POWER FAULT STATES 

) 

(aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(30BJECT= MixerJJni t_Coupl ing_to_System 
OCLASSES= 

ZERO_POWER FAULT_STATES 

) 

(aPROPERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

<aOBJECT= Mixer Unit Genera l_Fai lure 
<aCLASSES= 

HIGH POWER FAULT_STATES 
LOW_POWE R_FAU LT_S TATES 
ZERO POWER_FAULT_STATES 

) 

(3PR0PERTIES= 

DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 
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(©OBJECT 3 Undef ined_General_Fai lure 
(©CLASSES 3 

H I GH_POWER_FAULT_S TATES 
LOW POWER_FAULT_STATE$ 
ZERO_POWER_FAULT_STATES 

) 

(©PROPERTIES 3 

DESCRIPTION 

INF_CATEGORY 

VERIFIED 

> 

) 

(©OBJECT 3 

ZZ_Outstanding_Fault_States_for_Channel_2_Upconver 

ter System 
"(©CLASSES 3 

HIGH_POWER FAULT_STATES 
LOW POWER_FAULT STATES 
zero_power_faulT_states 

) 

(©PROPERTIES 3 
DESCRIPTION 
INF CATEGORY 
VERIFIED 

) 

) 

(©SLOT 3 

HPADIPC_Attenuator_Coupl ing_to_System.VERI FIED 

©INFATOM=HPADIPC Attenuator_Coupl i ng_to_System. INF 
_CATEGORY; 

) 

(©SLOT 3 HPAD I PC_At tenuator_General_Fai lure. VERIFIED 

©INFATOM=HPADIPC_Attenuator_General_Fai lure. INF_CA 
TEGORY; 

) 

(©SLOT 3 

HPAD I PC_Attenuator_$ett i ng_I s_I ncor rect .VERIFIED 

©I NFATON=HPAD I PC At t enuator_Set t i ng_I s J ncorrect . I 
NF CATEGORY; 

) ” 

(©SLOT 3 

HPAIPC_Ampl l f i er_Coup l i ng_t o_Syst em. VER I F I ED 

a I N F ATOM 3 H PA I PC_Amp l i f i e r_Coup l i ng_ t o_Sys t em . I N F_C 
ATEGORY; 

) 

(©SLOT 3 HPA I PC_Ampt i f i er_Genera l_Fa i lure.VERI FIED 

©INFATOM=HPAIPC_Ampl if ier_General_Fai lure. INF_CATE 
GORY; 

) 

(©SLOT 3 

HPAIPC_Ampl if ier_Power_Supply_Fai lure.VERI FIED 

©INFATOH 3 HPAIPC_Ampl if ier_Power_Supply_Fai lure. INF 
_CATEGORY; 

) 

(©SLOT 3 

HPA I PC_A 1 1 enua t or_Coup l i ng_t o_Sy s t em . VE R I F I ED 

© I N FATOM=HPA 1 PC_At t enua t o r_Coupl i ng_t o_Sys t em . INF_ 
CATEGORY; 


) 

(©SLOT 3 HPAlPC_Attenuator_General_Fai lure.VERI FIED 

©INFATOH=HPAIPC Attenuator_General_Fai lure.INF_CAT 
EGORY; 

) 

(©SLOT 3 

HPAIPC_Attenuator_Setting_Is_Incorrect. VERIFIED 

©INFATOH 3 HPAIPC Attenuator_Sett ing_Is_I ncorrect . IN 
F CATEGORY; 

r 

(©SLOT 3 

Local Osci l lator_Frequency_$etting_Is_Incorrect.VE 
RIFIED 

©INFATOM=Local_Oscillator_Frequency_Setting_Is_Inc 

or rect. INF CATEGORY; 

) 

(©SLOT 3 Local_Osci l lator_General_Fai lure.VERI FIED 

©INFATOH=Local_Osci l lator_General_Fai lure. INF_CATE 
GORY; 

) 

(©SLOT 3 

Local_Osci Uator_Out_of_PhaseJ.ock Alarm. VERI FIED 

©INFATOM=Local Oscillator Out_of_Phase_Lock Alarm 

.INF CATEGORY;" 

) 

(©SLOT 3 

Local Osci l lator_Out_of_Phase_Lock Test.VERIFIED 

©INFATOM=Local_Osci l lator_Out_of_Phase_Lock Test. 

I NF_C ATEGORY; 

) 

(©SLOT 3 

Loca l_Osc i 1 1 at or_Power__Supply_Fa i l ure .VERIFIED 

©INFATOH=Local Osci llator_Power_Supply_Fai lure. INF 
_CAT EGORY; 

> 

(©SLOT 3 

Local_Osci 1 1 ator_Si gna l J>ower _Leve l_I s_LOW .VERIFIED 
©INFATOH=Local Osci l lator_Signal_Power__Level_Is_LO 

U.lNF_CATEGORY; 

) 

(©SLOT 3 Mixer_Unit_Coupling_to_System. VERIFIED 

©INFATOM=MixerJJni t_Coupl ing_to__System. INF_CATEGOR 
Y; 

) 

( ©SLOT 3 Hi xer_Un i t_Gener a l_F a i l ure .VERIFIED 

©INFATOH=Hixer Unit General_Fai lure. INF_CATEGORY; 

) 

(©SLOT 3 Undef ined_General_Fai lure.VERI FIED 

© I N FATOM=Undef i ned_Gener a l_Fa i l ur e . I N F_CATEGORY; 

) 


(3$L0T= 

ZZ_Outstanding_Faul t_States_f or_Channel_2_Upconver 

ter System. VERT f I E\ 

D 

3INFAT0M=ZZ_0utstanding_Faul t_States_for_Channel_2 
Upconverter_System. INF_CAT\ 

EGORY; 

) 

(SRULE= R1 
(3LHS= 

(Is ( < | SUBSYSTEMS | > . POUER _LEVEL_OUT ) 
("HIGH")) 

(Yes 

( < | H I GH_POWER_FAULT_STATES | > . VER I F I ED ) ) 

(3HYP0= Diagnose HIGH _Power_Faul t_States) 

) 

(3RULE= R2 
(3LHS= 

(Is < < | SUBSYSTEMS J > . POUER J-EVELJDUT ) 

("LOW”)) 

(Yes 

( < | LOW_POWER _FAULT_STATE$ J > . VER I F I ED ) ) 

(3HYP0= Diagnose_LOW_Power_Fault_States) 

) 

(3RULE= R3 
(3LHS= 

(Is (<| SUBSYSTEMS [ > . POUER J.EVEIJXJT ) 
("ZERO")) 

(Yes 

( < j ZERO_POWER_FAULT_STATES | > . VER I F I ED ) ) 

(3HYP0- Diagnose_ZERO_Power_Fault_States) 

) 
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